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1  Summary  of  the  Research 

Wireless  Integrated  Network  Sensors  (WINS)  technology  is  a  complete  system  of  autonomous 
sensors,  actuators,  and  processors  linked  by  self-assembled  wireless  networks.  WINS  networks  of 
sensors  and  controls  form  the  bridge  between  the  global  Internet  and  the  physical  world.  WINS 
nodes  are  compact,  low  power  devices  that  may  be  rapidly  deployed  or  installed  at  low  cost.  WINS 
are  the  first  entry  into  a  future  of  widely  distributed  Internetworked,  wireless,  embedded  processors, 
sensors,  and  controls  for  security  and  other  applications.  WINS  demonstrations  have  shown  that 
defense  systems  will  be  fundamentally  changed  by  low  cost  devices  which  are  deeply  and  widely 
distributed  in  environments  and  integrated  into  assets  for  continuous,  global  monitoring  and  control 
for  batdefield  surveillance,  security,  environmental  status,  and  condition  based  maintenance.  There  is 
now  a  confirmed  set  of  WINS  applications  within  the  Department  of  Defense  for  battlefield 
surveillance  and  condition  based  maintenance  on  land,  sea,  and  air  vehicles.  In  addition,  through  the 
development  at  Sensoria  Corporation,  WINS  networks  are  now  Internet  accessible,  enabling  global, 
remote,  reconfigurable  monitoring,  control,  and  security. 

Within  the  WINS  NG  program,  Sensoria  Corporation  provided  to  both  the  Sensor  Information 
Technology  (SensIT)  DARPA  IXO  coordinated  development  group,  and  to  the  Naval  Research 
Laboratory  SRSS  Network  research  program,  WINS  development  platforms,  development  support, 
and  supporting  research  on  improved  WINS  systems.  This  research  included  three  generations  of 
sensor  development  systems  providing  capabikties  for  both  basic  research  on  WINS  systems,  and  for 
field  deployment  during  real  world  experiments. 

2  Introduction  to  the  WINS  Next  Generation  Program 

The  deployment  of  WINS  in  the  primary  defense  appkcations  for  battlefield,  perimeter,  and  base 
security,  as  well  as  condition  based  maintenance  environments,  requires  a  low  cost,  scalable,  self¬ 
installing  architecture.  The  full  advantage  of  WINS  requires  that  these  devices  be  densely  distributed 
in  the  environment.  This  ensures  that  WINS  sensing  elements  are  located  in  relative  proximity  to 
potential  threats  and  that  multiple  nodes  may  simultaneously  be  brought  to  bear  on  threat  detection 
and  assessment.  This  dense  distribution,  when  combined  with  proper  networking,  enables  mulfihop, 
short-range  communication  between  nodes.  This  drastically  reduces  the  most  important  WINS 
power  demand,  communication  operating  power.  Additional  innovations  in  WINS  include  devices 
that  are  continuously  vigilant,  sensing  and  processing  all  sensor  data  for  the  purpose  of  detecting  the 
presence  of  a  threat.  The  WINS  nodes  communicate  only  network  management  status  (and 
synchronization)  information  except  in  the  event  of  threat  detection.  In  this  event,  the  WINS 
network  carries  only  threat  event  codes  (pointers  corresponding  to  codebook  entries  for  identified 
threat  signals),  efficiently  communicating  the  presence  and  nature  of  a  threat.  In  the  event  that  a 
threat  is  detected,  but  not  identified,  larger  datasets  must  be  migrated  to  a  remote  user.  The  scalability 
of  this  WINS  network  depends  on  powerful  local  computation  capability,  adaptation  to  the 
environment,  remote  reconfigurability,  and  communication  security.  These  capabkifies  are  being 
provided  in  this  program  by  technologies  and  innovations  in  WINS  Internetworking  by  Sensoria 
Corporation.  In  addition,  a  new  WINS  architecture  supporting  the  required  rapid  delivery  has  been 
supplied  as  a  powerful  development  platform  to  the  DARPA  SensIT  research  community,  and  to  the 
NRL  SRSS  program. 

The  DARPA  SensIT  program  leads  the  mission  to  develop  the  Information  Technology  required  for 
deeply  distributed,  networked,  inexpensive  and  pervasive  platforms.  These  combine  multiple, 
reprogrammable  general-purpose  processors,  and  wireless  communication  systems.  The  SensIT 
community  includes  the  leaders  in  fields  ranging  from  the  development  of  diffusion  protocols  for 
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mialti-hop  routing  through  tactical  sensor  signal  processing.  A  powerful  WINS  platform  is  required 
for  the  development  of  SensIT  software  systems. 

The  NRL  SRSS  program  extends  on  the  work  done  in  the  SensIT  community  to  further  investigate 
networking  solutions  appropriate  for  WINS  systems,  as  well  as  considering  additional  radio  interfaces 
via  building  on  the  WINS  NG  development  systems. 

Sensoria  Corporation  has  developed  multiple  generations  of  a  new  WINS  architecture,  WINS  Next 
Generation  (WINS  NG),  to  address  the  most  important  WINS  defense  applications  that  are  now 
emerging.  The  WINS  NG  architecture  includes  WINS  nodes  operating  as  sensor  and  control 
devices,  WINS  nodes  operating  as  network  gateways,  WINS  server  functions,  and  WINS  Internet 
applications.  The  WINS  NG  platform,  distributed  to  the  SensIT  community,  permits  the 
development  of  self-organking  networks  robust  multi-hop  routing  methods,  network-enabled  data 
correlation,  and  language  interfaces  for  querying  and  tasking.  The  WINS  NG  platform  is  also  being 
exploited  by  Sensoria  Corporation  (formerly  known  as  Sensor.com)  to  develop  new  network,  signal 
processing,  and  event  recognition  methods  along  with  adaptive  and  reconfigurable  sensing  and 
communication  systems,  within  their  WINS  NG  program. 

2.1  WINS  Next  Generation:  Approach 

The  WINS  NG  program  provides  an  advance  in  tactical,  distributed  sensor  technology.  In  addition, 
the  WINS  NG  platforms  provides  a  development  opportunity  for  the  SensIT  and  NRL  SRSS 
Communities  by  supporting  their  requests  and  needs  through  multiple  generations  of  the  WINS  NG 
development  platforms. 

The  WINS  NG  program  has  supplied  the  multiple  WINS  NG  platforms  to  the  SensIT  and  NRL 
SRSS  communities.  WINS  NG  combines  high  performance  sensing,  actuator  control,  frequency- 
hopped  spread  spectrum  communication  and  GPS  location  capability.  The  WINS  NG 
multiprocessor  computing  platform  provides  a  micro-power,  constantly  vigilant  real  world  interface, 
as  well  as  a  32-bit  platform  for  power  computation.  Software  APIs  provide  access  to  sensing,  signal 
processing,  communication,  networking,  and  platform  management  for  each  processor. 

The  WINS  architecture  design  addresses  the  constraints  on  robust  operation,  dense  and  deep 
distribution,  interoperability  with  conventional  networks,  operating  power,  scalability,  and  cost. 
Robust  operation  and  dense,  deep  distribution  benefit  from  a  multihop  architecture  where  the 
naturally  occurring  short  range  links  between  nodes  is  exploited  to  provide  multiple  pathways  for 
node-to-node,  node-to-Gateway,  and  Gateway-to-network  communication.  WINS  Gateways  provide 
support  for  the  WINS  network  and  access  between  conventional  network  physical  layers  and  their 
protocols  and  the  WINS  physical  layer  and  its  low  power  protocols. 

Over  the  course  of  the  WINS  NG  contract,  Sensoria  Corporation  has  researched,  developed,  and 
supplied  multiple  versions  of  the  WINS  NG  networked  sensor  development  platform,  to  enable  the 
wider  research  community.  Over  the  course  of  this  effort,  three  versions  of  the  WINS  NG  platform 
have  been  developed,  with  over  180  of  the  1.0  and  2.0  platforms  provided  to  the  SensIT  community, 
including  a  variety  of  sensing  interfaces,  including  imaging.  This  technical  report  provides  a  summary 
of  the  research  conducted  by  Sensoria  over  the  course  of  this  program,  and  of  the  platforms 
developed  or  refined  in  conjunction  with  that  research,  in  order  to  enable  the  initial  SensIT 
development  community. 
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3  WINS  NG  1.0  Sensor  Development  Platform 

To  quickly  supply  the  SensIT  community  with  a  development  system  to  enable  testing  of  networked 
sensor  algorithms  early  in  the  WINS  NG  program,  we  developed  and  supplied  the  WINS  NG  1.0 
sensor  development  platform.  This  platform  leveraged  Sensoria  Corporation’s  past  development 
experience  in  order  to  supply  this  platform  to  the  community  starting  in  December  1999.  Features 
of  the  platform  are  summarized  below  with  further  details  provided  in  the  following  sub-sections. 


WINS  Network  Nodes 


WINS  Next  Generation  Node 
(WINS  NG) 


The  WINS  Node  is  the  intelligent,  ubiquitous 
networked  device  of  the  Computing 
Continuum. 

The  WINS  Node  provides  the  direct  and 
distributed  interfaces  to  the  physical  world. 
The  WINS  NG  System  is  a  unique  architecture 
that  provides: 

•  Physical  Interfaces: 

•  Multiple  analog  sensor  interfaces 

•  Multiple  parallel  digital  interfaces 

•  Multiple  serial  digital  interfaces 

•  Global  Positioning  System  (GPS) 

•  Computation  and  Signal  Processing 

•  Real  time  preprocessor 

•  32  bit  processor  and  operating  system 

•  Communication  and  Networking 

•  2.4  GHz  frequency  hopped  spread 
spectrum  low  power  communication 

•  Energ)i  and  Platform  Management  Systems 

•  Ijocal  Graphical  User  Inteface 

•  WINS  Gateway 

•  Programmable  network  interfaces 
to  networks  including  Ethernet 
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WINS  Development 
Platforms 


The  WINS  NG  Development  platform 
includes  Ethernet  and  serial  access  to  WINS 
NG  Node  development  ports  providing  a 
networked  workstation  development 
environment. 

•  WINS  Server 

•  WINS  SQL  Server 

•  WINS  mb  Access 


The  WINS  NG  1.0  network  architecture,  shown  in  Figure  1,  includes  WINS  NG  Nodes,  Gateways, 
Server  and  Web  access  components.  WINS  NG  nodes  have  been  distributed  in  the  environment  for 
threat  detection,  identification,  and  location  during  the  early  stages  of  the  SensIT  program.  Sensors 
attach  to  the  WINS  node  and  include  seismic,  acoustic,  and  infrared  detection.  Local  signal 
processing  at  the  WINS  node  enables  constantly  vigilant  monitoring  of  sensor  signals  for  detection 
and  identification.  Microprocessor  systems  in  the  node  provide  adaptive,  distributed  computing 
resources  for  network  management.  Finally,  a  local  area,  low  power  wireless  modem  is  designed  for 
support  of  a  messaging  network. 


user 


Figure  1.  The  WINS  NG  network  architecture  includes  WINS  NG  Nodes,  Gateways,  Server  and  Web  access 

components. 

The  WINS  NG  node  architecture  is  shown  in  Figure  2.  This  architecture  has  been  developed  to 
provide  support  for  both  real-time,  constantly  vigilant  signal  processing  and  support  for  software 
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development  in  non-real  time  platforms.  The  architecture  diagram  shows  the  sensor,  signal 
processing,  and  preprocessor  components.  All  of  the  components,  other  than  the  processor,  operate 
at  a  high  or  full  duty  cycle.  All  of  these  sensing  and  signal  processing  components  must  continuously 
monitor  the  environment  for  threat  status.  However,  the  processor  need  operate  only  upon  demand. 
Processor  operation  may  occur  to  compute  a  new  networking  solution,  adapt  a  detection  algorithm, 
or  process  a  complex  threat  signal.  However,  this  operation  may  generally  be  performed  at  low  duty 
cycle. 


WINS  Preprocessor  WINS  Processor 


micropower 
preprocessor 
constant  operation 


low  power 
low  duty  cycle 
processor 


Figure  2.  The  WINS  NG  Node  Architecture.  This  architecture  has  been  developed  to  provide  support  for 
both  real-time,  constantly  vigilant  signal  processing  and  support  for  software  development  in  non-real  time 

platforms. 

3.1  WINS  NG  1.0  Platform  Components 

The  WINS  NG  1.0  Platform  components  illustrated  in  Figure  2  are  described  further  in  the 
following  subsections. 

3.1.1  WINS  NG  1.0  Sensors 

The  original  WINS  NG  1.0  sensors  included  a  seismic  geophone  sensor,  an  acoustic  sensor,  and  an 
infrared  motion  sensor  system.  In  addition,  a  GPS  position  sensor  was  also  included.  Finally,  analog 
input  and  digital  I/O  support  was  provided  for  contractors  who  wish  to  develop  custom  sensor 
systems.  Further  details  on  the  sensing  capabilities  of  the  WINS  NG  1.0  nodes  are  shown  in  Table  1. 
Each  WINS  NG  node  was  equipped  with  a  seismic,  acoustic,  and  infrared  sensor,  as  well  as  a  GPS 
receiver. 

The  WINS  NG  Sensors  were  developed  for  tactical  applications.  The  sensors  and  sensor  interfaces 
follow  the  specifications  of  devices  used  in  the  leading  DOD  reference  tactical  sensor  data 
acquisition  systems.  These  systems  met  or  exceeded  the  performance  of  the  tactical  sensors  in  the 
field  at  the  dme  of  use  within  the  SensIT  program.  These  threat  detection  sensors  include  seismic, 
acoustic,  and  infrared  motion  devices.  GPS  modules  are  included  as  well  for  location  and  time 
references. 
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Phenomena 

Sensor  Type 

Specifications 

Package  Type 

Seismic 

Geophone 

Resonant  Frequency  10  Hz 

Coil  characteristics  395 f2 

Peak  Responsivity  Velocity 

responsivity  of 
0. 70  V/in/sec 

External  remote  sensing 
case  with  cable.  Two 
packages  are  available  one 
with  a  butterfly  tripod,  and 
one  with  a  spike  for  two 
sensor-to-surface  coupling 
options 

Omnidirectional 

Acoustic 

Electret 

compact 

microphone 

Sensitivity 

-44dB 

(OdB^lV/Pa) 

External  remote  sensing 
case  with  cable. 

Frequency  Range 

20Hz  -  20kHz 

S/N  Ratio 

>58dB 

Passive 

Infrared 

Pyroelectric 

infrared 

sensor 

Coverage  out  to  13.5  m  (45  ft). 
Enhanced  20  V/m  RFI  immunity  with 
visible  light  rejection  filter 

External  remote  sensing 
case  with  cable.  Includes  a 
Velcro  mount  orienting  the 
field  of  view.  Sensor  is  7  x 
2.8  X  2.5  cm 

Update  Rate: 

10/sec 

Cold  Start: 

1  min.  average 

12 

channel 

GPS 

Warm  Start: 

40s  average 

GPS 

Hot  Start: 

8s  average 

Integrated  into  node  with 
six  foot  cable  for  magnetic 

receiver 

Reacquisition 

Time: 

100ms 

mount  antenna  placement. 

Minimum  Signal 

-175  dBW 

Output: 

NMEA  Protocol 

Table  1:  Summary  of  WINS  NG  1.0  Sensors. 


3.1.1.1  WINS  NG  Sensor  Interface  System  Specifications 

The  WINS  NG  Node  sensor  inputs  include  fully  conditioned  analog  input  sampling  for  tactical 
sensors.  These  inputs  include  amplifiers,  controllable  anti-aliasing  input  filters,  and  input  analog  to 
digital  converters.  The  sensor  interface  specifications  are  listed  in  Table  2. 
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Parameter 

Channel 

Conditions 

Typ 

Unit 

Gain 

Ch  1&2 

1=20 

2=40 

3=58 

4=73 

dB 

Ch  3&4 

1=6 

2=20 

3=40 

4=60 

dB 

Frequency  Response 

Ch  1&2 

Frequency  response  is  limited  by 
a  5th  order  Butterworth  SC  fiiter. 
Corner  Frequency  is  determined 
by  the  sampling  clock:  8.192kHz 
&  32.768kHz 

Low  =  81.92 
High  =  327.6 

Hz 

Ch  3&4 

Frequency  response  is  limited  by 
a  1-pole  RC  LPF  at  the  input  to 
the  ADC. 

2.3kHz 

Hz 

Input  Impedance 

Ch  1&2 

Both  inputs  are  AC  coupied  and 
referenced  to  2.5V.  impedance 
valid  above  1  Hz 

100x10^ 

Q 

Ch  3&4 

Both  inputs  are  AC  coupied  and 
referenced  to  2.5V.  impedances 
valid  above  1  Hz 

20x10® 

Q 

Input  Voltage  Range 

Ch  1&2 

Both  inputs  are  AC  coupied  and 
referenced  to  2.5V. 

(1.9  -  3.8) 

V 

Ch  3&4 

Both  inputs  are  AC  coupied  and 
referenced  to  2.5V. 

(0  -  3.5) 

V 

Input  Referred  Noise 

Ch  1&2 

@  10Hz 

20dB=650 

40dB=100 

58  &  73dB=50 

nV/(rtHz) 

Ch  3&4 

@  10Hz 

35 

nV/(rtHz) 

Table  2:  WINS  NG  1.0  sensor  interface  specifications. 


3.1.2  WINS  NG  Preprocessor 


The  WINS  NG  Preprocessor  is  shown  in  Figure  3.  This  includes  the  Sensor  Interface  Processor 
(shown  in  Figure  4).  The  Preprocessor  is  a  low  power  component  with  sleep  control  capability.  The 
Preprocessor  includes  the  following  components: 

Sensor  Interface  Processor  including  a  static  CMOS  microprocessor  and  sampling  system.  The 
sampling  system  includes  a  set  of  programmable,  switched  capacitor,  analog  anti-aliasing  input  filters. 

Control  Processor  including  a  Z180L  -  low  power  microprocessor  equipped  with  512K  SRAM  and 
128K  of  flash  memory. 

Serial  I/O  Ports  are  included  with  the  Preprocessor. 
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Figure  3.  The  WINS  NG  Preprocessor.  This  includes  the  Sensor  Interface  Processor  (shown  in  Figure  4).  The 
Preprocessor  is  a  low  power  component  with  sleep  control  capability. 


physical 

signal 


sensor 


interface 


buffer 


sampling  control 


sampling  processor 


to 

preprocessor 


sensor  interface  processor 


Figure  4.  The  Sensor  Interface  Processor  including  a  static  CMOS  microprocessor  and  sampling  system.  The 
sampling  system  includes  a  set  of  programmable,  switched  capacitor,  analog  anti-aliasing  input  filters. 


Figure  5.  The  WINS  NG  Power  Supply.  The  WINS  NG  Power  Supply  is  a  low  power  system  intended  to 
support  a  multiplicity  of  sensors  and  interfaces  with  both  low  average  power,  and  high  peak  power 

performance. 


3.1.3  WINS  NG  Processor 

The  WINS  NG  system  operates  with  a  constandy  vigilant  Preprocessor  sampling  all  sensor  data. 
The  Preprocessor  is  responsible  for  data  acquisition  as  well  as  alert  functions.  Specifically,  in  the 
event  that  a  threshold  excursion  is  observed,  the  Preprocessor  detects  and  alerts  the  Processor.  The 
Processor,  which  may  have  been  operating  in  a  sleep  state,  is  now  available  for  signal  processing  and 
event  identification.  Further,  high  level  functions,  including:  cooperative  detection,  database 
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transactions  and  other  services,  may  now  be  negotiated  by  the  Processor.  At  all  times,  the  algorithms 
may  be  implemented  to  minimize  power  dissipation.  The  80  MHz  MIPS  processor  platform  has 
been  tested  for  throughput.  The  code,  which  will  be  supplied  in  source  code  as  part  of  the  kit  at  the 
WINS  NG  Short  Course,  includes  FIR  filters,  IIR  filters,  and  a  complete  spectrum  analyzer.  Filter 
generator  algorithms  will  be  supplied  as  well.  This  will  provide  the  developer  with  the  ability  to 
command  the  Node  to  locally  synthesize  a  complex  filter  without  a  large  demand  on  communication 
resources. 

Filter  throughput  requirements  depend  on  network  system  design.  Goals  for  distributed  sensor 
systems  are  to  reduce  the  ratio  of  sampled  sensor  bits  to  processed  or  communicated  bits.  However, 
for  testing  and  development  purposes,  it  will  be  convenient  for  the  WINS  NG  platform  processing 
speed  to  match  that  of  the  sensor  data  stream.  This  would  require  a  processing  rate  of  about  1000 
12-bit  words  per  second.  FIR  filters  and  FIR  filter  generators  have  been  implemented  with  the  32- 
bit  integer  data  type  and  the  64  bit  double  data  types.  Throughput  test  results  are  shown  in  Figure  6 
through  Figure  8. 


Time  Domain  64-Tap  FiR  Filter  Performance,  WinCE  MIPS  R4000 


Figure  6.  WINS  NG  Processor  throughput  test  for  a  64-tap  FIR  filter. 
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Time  Domain  128-Tap  FiR  Fiiter  Performance  WinCE  MiPS  R4000 


-  Int 

■  Double 


Figure  7.  WINS  NG  Processor  throughput  test  for  a  128-tap  FIR  filter. 


Time  Domain  512-Tap  FiR  Fiiter  Performance  WinCE  MiPS  R4000 


Figure  8.  WINS  NG  Processor  throughput  test  for  a  512-tap  FIR  filter. 


It  is  important  to  note  that  even  for  the  extreme  case  of  a  512-tap  FIR  filter,  data  throughput 
matches  the  incoming  word  rate  for  high  resolution,  32  bit  processing. 

The  WINS  NG  Processor  is  based  on  a  commercial  PDA  platform,  which  also  provides  a  user 
interface  at  the  node,  with  the  following  characteristics: 

•  MIPS  R4000  Processor  at  80  MHz  clock  rate 
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•  ROM  Memory  —  8  MB 

•  RAM  Memory  —  8  MB 

•  Touch  Screen 

•  Windows  CE  2.0  OS 

•  Ethernet  Interface 

3.1.4  WINS  NG  RF  Modem 


The  WINS  NG  RF  Modem  is  a  2.4  GHz  frequency  hopped,  spread  spectrum  system.  Sensor.com 
has  integrated  this  RF  Modem  with  a  dielectric  patch  antenna  system  to  enable  a  completely  sealed, 
internal  communication  solution.  This  is  mechanically  robust  and  convenient  for  deployment.  The 
WINS  NG  RF  modem  is  a  frequency  hopped  spread  spectrum  system  operating  in  the  unlicensed 
2.4  GHz  ISM  band.  Specifications  for  the  RF  modem  include: 

Signaling:  BFSK 

Spread  Spectrum:  Frequency  Hopping 


Hopping  Sequence  Choices: 
Addressing: 

Physical  Address: 

Operating  Band: 
Transmitted  Power: 


50 

Programmable 

6  byte  permanently  assigned  IEEE  802.3  address 

2.4000  -  2.4835  GHz 

lOmW 


Receiver  Sensitivity:  -90dBm 

Range:  Greater  than  100m  for  outdoor  and  typical  indoor 

environments 


RE  Modem 

Configuration:  As  is  required  for  robust,  frequency  hopped  spread 

spectrum  transceivers,  the  WINS  NG  RE  modems  operate 
in  a  master/slave  hierarchy,  where  the  master  modem 
provides  synchronization  for  many  slave  modems.  By 
default,  the  Gateway  modem  may  function  as  a  master. 
However,  this  is  not  required,  nor  always  optimal. 
Multihop  routing  occurs  between  the  clusters  that  are 
defined  by  the  current  status  of  the  RE  modems. 

RE  Modem 

Configuration  Control:  Each  WINS  NG  RE  modem  may  be  promoted  from  slave  to 

master  state  or  demoted  from  master  to  slave.  This 
capability  is  useful  in  providing  reconfigurability  and 
implementing  multicluster/multihop  communication. 
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Number  of  network 
nodes  supported  by 
single  Gateway: 

Communieation  Rate: 


Individual  Node  to  Gateway 
Communieation  Rate: 


Multiple  Nodes  to  Gateway: 

Data  Frame: 


At  least  50 


Defined  for  Individual  Node  to  Gateway  and  aggregate  of 
Multiple  Nodes  to  Gateway 


(Average  bit  rate  is  intended  to  be  low  for  densely 
distributed  sensors.  However,  for  development  purposes, 
bit  rate  may  be  inereased.  The  WINS  NG  system  is  designed 
to  provide  the  worst-case  high  bit  rate  that  would  occur  if 
no  information  processing  were  to  occur.  This  would 
support  continuous  streaming  of  unprocessed  sensor  data. 
Information  processing  will  reduce  this  bit  rate  for  the 
benefits  of  scalability  and  energy). 


Peak  air  interfaee  data  rate  will  be  greater  than  100  kbps. 

Preproeessor  to  Modem  interfaee  data  rates  will  be  lower 
than  the  air  interfaee  data  rate.  Typieal  applieations  will 
support  the  filling  of  the  RF  modem  transmit  buffer  over  a 
period,  followed  by  eommunieation  of  the  buffer  over  a 
short  interval  available  in  an  appropriate  TDM  A  frame. 
Additional  information  and  example  applieations  will  be 
provided  in  the  API  Speeifieations. 


Complete  system  speed  will  support  eontinuous  streaming 
of  sampled  data  for  at  least  one  WINS  NG  node  in  the 
network. 


Multiple  user  inputs  are  allowed  at  the  Gateway  modem. 


Detailed  data  transfer  funetions  with  the  RF  modem  are 
supported  by  the  WINS  NG  API,  whieh  was  supplied.  The 
Data  Frame  ineludes  the  format  shown  in  Figure  9. 
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Length 

Length 

Destination 

Source 

Data 

Checksum 

(low  order  byte) 

(high  order  byte) 

Address 

Address 

(up  to  2048  bytes) 

Figure  9.  WINS  NG  Data  Frame.  Unicast  and  Broadcast  addressing  are  supported. 


3.1.5  WINS  NG  Package 

The  WINS  NG  Package  is  a  sealed,  waterproof  system  that  Sensor.com  and  the  DOD  have 
employed  for  tactical  sensors  in  field  applications.  The  Package  contains  the  WINS  Preprocessor, 
Processor,  and  Sensors.  Sensors  may  also  be  deployed  externally  to  the  package  (particularly  in  the 
case  of  acoustic  and  infrared  motion  sensors.) 

While  equipped  with  rechargeable  batteries,  a  battery  eliminator  is  included  with  WINS  NG  for 
operation  during  development. 


Figure  10.  The  WINS  NG  environmentally  resistant  package.  Sensors  are  placed  external  to  this  package  for 

optimal  performance. 


3.2  WINS  NG  1.0  Software  API 

The  WINS  NG  Software  API  architecture  has  been  developed  and  is  shown  in  Figure  11.  The  API 
includes  low  level  functions  for  access  to  physical  world  interfaces,  as  will  be  described.  The  API 
also  includes  higher  level  functions  and  finally  the  support  for  the  full  SensIT  Applications. 
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Example  SenselT  Applications 


Event  Detection  /  Novel  Sensing 


Sensing 


□c 


General 

Purpose 

Sensor 

Interfaces 


GPS 

(NMEA 

Standard) 


Signal 

Processing 


Preprocessor 


Directed  Diffusion 


Network  API 


Communication 


RF  Modem 
Communication 


RF  Modem 
Control 


Figure  11.  The  WINS  NG  API  is  shown  including  low-level  functions  for  access  to  physical  world  interfaces 

and  support  for  the  full  SensIT  Applications. 


3.2.1  WINS  NG  Framework  Application:  WINS  NG  1.0  API 


To  fully  demonstrate  the  use  of  the  WINS  NG  APIs,  an  application  was  provided  with  the  platform. 
This  application,  referred  to  as  the  SensIT  Framework,  contains  access  to  functions  including 
sensing,  analog-to-digital  conversion  control,  automatic  gain  control,  GPS  access,  networking,  and 
platform  control.  Each  interface  provided  a  demonstration  of  these  API  functions. 

3.3  WINS  NG  1.0  Node  Power  Dissipation  Specifications 

Figure  12  shows  power  dissipation  for  WINS  NG  1.0  subsystems  for  all  subsystems  operating  at  full 
power  and  100  percent  duty  cycle.  This  data  may  be  used  to  select  subsystem  duty  cycle.  Depending 
on  operating  mode,  whether  standby,  vigilant,  or  full  alert,  each  of  the  subsystems  may  be  placed  into 
a  sleep  (power  off)  state. 
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Figure  12.  WINS  NG  1.0  Power  dissipation  by  subsystem 
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3.4  WINS  NG  1.0  Deployment  at  SITEXOO 


As  part  of  the  SensIT  program,  37  WINS  NG  1.0  nodes  were  setup  at  the  Marine  Corp  Air  Ground 
Combat  Center  (MCAGCC)  in  29  Palms  California,  operating  for  over  two  weeks  in  August  of  2002. 
This  represented  the  first  field  experiment  for  the  SensIT  program  and  was  a  combination  data 
collection  experiment,  algorithm  testing,  and  deployed  system  experiment.  Part  of  the  area  (an 
intersection  of  three  roads)  is  shown  in  Figure  13. 


Figure  13.  View  from  the  command  area  of  the  SITEX  test  site  at  the  MCAGCC,  29  Palms  CA. 


During  SITEXOO,  each  of  the  WINS  NG  nodes  was  deployed  off  the  ground  to  reduce  temperature 
at  the  node  (as  shown  in  Figure  14),  powered  off  of  marine  cells  (connected  to  multiple  WINS  NG 
1.0  nodes  so  they  could  be  left  for  weeks  out  in  the  field),  and  connected  over  Ethernet  back  to  a 
base  camp  so  all  data  collected  could  be  stored  and  the  operation  of  each  node  monitored. 

An  example  of  the  large  amount  of  data  collected  as  a  variety  of  military  targets  passed  on  the  road 
(both  planned  and  unplanned  data  collection  targets)  is  shown  in  Figure  15.  For  this  experiment 
multiple  data  runs  were  collected  including  targets  of  personnel,  personal  vehicles,  AAVs,  LAVs, 
HMMWVs,  Dragon  Wagons,  a  variety  of  trucks,  and  an  occasional  tank.  During  these  data  runs,  the 
WINS  NG  1.0  nodes  were  the  primary  data  collection  instrument,  and  also  enabled  the  testing  of 
distributed,  embedded  operation  of  detection  and  networking  algorithms.  The  distribution  of  WINS 
NG  1.0  nodes  during  SITEXOO  can  be  seen  in  Figure  16,  for  which  the  detections  seen  at  local  nodes 
as  an  AAV  passed  are  shown,  as  well  as  in  Figure  1 7,  where  a  close-up  of  the  intersections  is  shown 
with  passive  infrared  detections  of  personnel. 
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Time 


Sensor  #1  Update  1 


Sensor  #2  Update  1 


Sensor  #3  Update  1 


Figure  15.  Example  data  collected  from  a  seismic  (#1),  acoustic  (#2),  and  passive  infrared  (#3)  sensor  on  a 

WINS  NG  1.0  node  at  SITEXOO. 
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Figure  16.  Display  of  data  collected  on  WINS  NG  1.0  nodes  as  an  AAV  (shown  in  the  inset)  passed.  Sensor 
detections  are  shown  with  green  circles  and  colors  coordinated  to  the  sensor  detection  type,  with  node 

locations  shown  in  white. 


Figure  17.  Display  of  Infrared  detections  by  WINS  NG  1.0  nodes  as  a  column  of  infantry  (shown  in  the  time- 

stamped  picture)  pass. 
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3.5  WINS  Imager 


To  complement  the  WINS  NG  1.0  sensor  development  nodes  we  provided  to  SensIT,  the  Sensoria 
WINS  Imager,  developed  previous  to  the  WINS  NG  program,  was  also  provided  to  the  SensIT 
community  and  further  refined  within  the  early  part  of  the  WINS  NG  program.  The  WINS  (Wireless 
Integrated  Network  Sensor)  Imager  provides  remotely  operated  imaging  capability  over  multi¬ 
kilometer  distances.  The  Imager  system  is  pictured  in  Figure  18.  The  Imager  consists  of  three 
components:  the  remotely  deployed  CCD  image  capture  system,  the  wireless  modem  attached  to  a 
laptop  over  a  serial  interface,  and  the  software  GUI  to  enable  communication  with  and  control  from 
the  attached  laptop  computer.  The  WINS  Imager  provides  the  capability  to  trigger  image  capture 
through  a  local  wired  input,  such  as  a  fluctuation  on  a  passive  IR  sensor,  or  through  a  remote  request 
on  the  wireless  channel,  or  though  activation  via  a  wired  connection  to  a  nearby  WINS  NG  1.0  node. 

3.5.1  Imager  Architecture 

The  WINS  Imager  system  is  pictured  in  Figure  18.  The  system  consists  of  the  remotely  deployed 
Imager  (A),  the  wireless  modem  to  which  the  interface  responds  and  transmits  images  (B),  and  the 
software  control  running  on  a  workstation  (C)  to  view  and  request  pictures  through  the  attached 
modem.  The  remote  Imager  provides  both  a  wireless  interface  to  request  pictures  as  well  as  a  local 
interface  to  trigger  picture  operation.  Shown  in  Figure  18,  the  Imager  is  triggered  with  a  passive 
infrared  detector.  Additional  triggering  options  are  shown  in  Figure  19.  These  include  a  wide-angle 
infrared  detector,  a  narrow  beam  infrared  detector,  a  locally  triggered  switch  corresponding  to  the 
different  triggering  conditions  associated  with  the  TASS  system,  and  a  wired  connection  to  an 
autonomous  WINS  NG  1.0  node  to  enable  local  processing  and  autonomous  decisions  about  image 
acquisition. 


Figure  18.  WINS  Imager  Setup  with  passive  infrared  trigger. 
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Figure  19.  Imager  triggering  options.  All  are  interchangeable. 


The  Sequence  of  events  in  the  WINS  Imager  operation  is  as  follows. 

•  The  Imager  receives  a  request  to  trigger,  either  remotely  from  the  laptop  interface,  or 
through  one  of  the  local  triggering  options  shown  in  Figure  19. 

•  The  Imager  acquires  an  image  at  a  fixed  delay  after  the  request  was  made. 

•  The  Imager  communicates  with  the  laptop  through  the  modem  with  notification  of  a 
picture.  At  the  instant  the  laptop  receives  this  notification  it  time  stamps  the  picture. 

•  The  image  is  uploaded  to  the  laptop.  During  this  process  the  Imager  software  GUI  displays 
the  progress  of  picture  transfer  in  terms  of  the  number  of  bytes  received  (see  Figure  20). 
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Figure  20.  WINS  Imager  stand-alone  Laptop  interface. 

3.5.2  Imager  Software 

The  WINS  Imager  software  GUI  is  shown  in  Figure  20.  The  interface  provides  both  display  and 
control  capabilities.  Images  may  be  transferred  as  a  thumbnail,  a  full  image,  or  both  after  they  are 
taken,  depending  on  the  trigger  cause.  A  number  of  different  image  triggers  are  supported.  These 
correspond  to  the  five  options  dictated  by  the  TASS  system,  for  which  the  Imager  was  initially 
developed.  Additionally,  the  interface  provides  the  capability  to  load  the  last  picture  taken  after  the 
GUI  is  restarted  and  to  cycle  through  the  pictures  as  the  images  are  being  taken. 

In  addition  to  providing  the  GUI  shown  in  Figure  20,  Sensoria  has  also  provided  a  sockets  interface 
so  that  each  of  the  commands  and  controls  of  the  GUI  may  be  seamlessly  integrated  into  another 
developer’s  interface  or  sensor  system.  This  facilitates  development  of  complete  systems  integrating 
the  Imager  capability,  with  additional  sensing  and  distributed  decision-making.  In  the  sockets 
interface,  there  are  two  functions  that  a  programmer  will  need  to  use  in  order  to  communicate  with 
the  WINS  Imager  Server  Program;  SendWINSImager  and  ReceiveWINSImager.  These  two 
programs  let  a  developer  interface  with  the  GUI  of  Figure  20,  when  the  GUI  is  minimized  in  order 
to  provide  all  the  functionality  and  response  incorporated  into  the  WINS  Imager  GUI. 


3.5.3  Imager  Network 

The  WINS  Imager  transmits  status  updates,  requests,  and  images  taken  to  the  attached  FHSS 
2.4GHz  modem.  This  modem  requires  a  9V  input  (through  the  included  120V  AC  to  9V  DC 
adapter)  in  addition  to  a  serial  interface  to  the  laptop  on  which  the  WINS  Imager  software  is 
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operating.  The  Imager  to  modem  link  has  been  demonstrated  operating  robusdy  over  a  1.5km  link, 
with  the  Imager  on  the  ground  and  the  modem  near  the  peak  of  a  nearby  hill,  without  line  of  sight 
between  the  two  antennas.  The  1.5km  demonstrated  link  is  seen  in  the  picture  on  the  Imager  display 
of  Figure  20,  where  the  modem  was  on  the  hiU  off  in  the  distance  and  the  Imager  was  placed  on  the 
ground.  Distances  out  to  10km  are  achievable  with  judicious  placement  of  the  Imager  and  modem 
for  an  optimal  line  of  sight  link. 

The  WINS  Imager  modem  of  Figure  18  (B),  includes  an  antenna  within  the  RF  permeable  packaging. 
The  Imager  itself  uses  an  omni-directional  detachable  dipole.  Increased  range  links  between  the  two 
units  may  be  most  easily  achieved  by  elevating  both  units. 


3.5.4  WINS  Imager  Specifications 

Specifications  on  the  capabikties  of  the  WINS  Imager  utilized  in  the  early  part  of  the  SensIT 
program  as  part  of  the  WINS  NG  program  are  given  in  Table  3  to  Table  7. 


Focus  range 

4  in.  -  infinity 

Horizontal  FOV 

55° 

Vertical  FOV 

39  °  (19.5  °  half-angle  off  the  ground) 

Recording  Image 

640  X  480 pixels 

Shutter  Speed 

Vi  - 1/500  sec.  (mechanical  shutter) 

Table  3:  CCD  Solid-state  Image  Pickup  Element. 

Battery  Lifetime 

50+  pictures  continuous  use 

4+  hour  standby  operation* 

Battery  charging  time 

12  hours  from  uncharged** 

Adapter 

120V  60Hz  to  12V DC  in 

Power  Draw 

130mA  at  12V idle 

500mA  at  12V for  Is  while  capturing  image 

425mA  for  50-60s  while  transmitting  image*** 

*With  remaining  battery  power  to  take  and  transmit  at  least  one  picture,  for  this  number 
the  radio  and  processor  is  always  on. 

**  Charging  for  2  hours  from  uncharged  allows  one  picture,  50+  pictures  are  available  after  12 

hours. 

***Dependent  on  image  size,  which  is  dependent  on  image  contrast  and  brightness 

Table  4:  Remote  Camera  Power  Specifications. 
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Temperature 

0  -  40  °C  (operating) 

-20  -  60  °C  (storage) 

Humidity 

20-90%  (operation) 

10-90%  (storage) 

Table  5:  WINS  Imager  operating  environment. 

Delay  in  Time  Stamping 

Image  time  stamped  at  Laptop  4s  after  image  is  taken 

Delay  in  requesting  through  a  WINS 
NG  1.0  Node 

2300±100ms* 

Delay  in  Requesting  from  the  Laptop 

15s  average,  ranges  from  2.5s  to  22s** 

Delay  in  triggering  from  IR  or  switch 

2100±200ms*** 

Time  Stamp  Set 

By  the  laptop  clock,  4s  after  picture  is  taken 

Minimum  time  between  pictures 

71s 

Time  to  download  thumbnail  when 
triggered  locally 

12s  after  the  picture  is  taken 

*Limited  by  Windows  CE  delay  variation  in  switching  threads.  This  was  measured  with 
automatic  triggering  based  on  Windows  CE  timing,  and  with  data  sampling  stopped  and  the 
radios  off  on  the  1.0  node  to  limit  latency. 

**Latency  variability  results  since  the  Imager  not  the  modem  initiates  communication,  and 
communication  is  duty  cycled  to  reduce  battery  drain. 

***  Higher  consistency  expected,  this  measured  value  is  limited  by  the  human  error  in  the 
triggering  measurements 

Table  6:  Timing  Specifications. 

Interfacing  Laptop  OS 

Windows  2000/  Windows  NT 

Recommended  Laptop  Speed 

350MHz  Pentium  H  or  higher 

EHSS  radio  Transmit  Power 

IWin  the  2.4-2.4835GHz  ISM  band 

Thumbnail  size 

4048  Bytes 

Eull  Image  Size 

40-65  kBytes 

Table  7:  WINS  Imager  General  Specifications. 

3.5.5  Use  of  the  WINS  Imager  at  SITEX01 

The  WINS  Imager  system  was  integrated  with  a  Base  Station  and  power  systems  for  deployment  at 
the  SensIT  Situational  Experiment  (SITEXOO  and  01)  in  conjunction  with  the  WINS  NG  1.0 
development  nodes.  The  capabilities  of  this  integrated  system  include: 

1 .  WINS  Imager  Base  Station  Display 
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2.  Wireless  access  to  a  remote  position  at  Base  Camp  Promontory 

3.  Local  cueing  of  WINS  Imager  with  local  sensor  inputs  and  remote  Imager  control  and  image 
acquisition 


Figure  21.  WINS  Imager  Base  Station  User  Interface.  This  base  station  was  located  at  the  Base  Camp 

Promontory  shown  below. 


Figure  22.  SITEXOO  demonstration  area,  indicating  the  deployment  of  the  WINS  Imager  and  the  Base  Camp 

Promontory  sites. 
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Figure  23.  Typical  images  obtained  with  the  WINS  Imager  operating  at  the  remote  site  in  the  SITEX  exercise. 

3.6  WINS  NG  1.0  Summary 

The  SensIT  community  utilized  sixty  of  the  WINS  NG  1.0  development  platforms  plus  one  WINS 
Imager  prototype  in  the  first  year  of  the  program.  During  the  use  of  these  platforms,  a  number  of 
lessons  were  learned,  and  research  progressed  on  the  development  platform  APIs,  on  the  platform 
capabilities,  and  on  the  network  support.  These  lessons  learned  within  Sensoria  Corporation  were 
combined  with  user  feedback  from  the  SensIT  community  to  develop  and  produce  the  WINS  NG 
2.0  sensor  development  platform  and  WINS  2.0  Imager  discussed  in  the  following  section. 


4  WINS  NG  2.0  Sensor  Development  Platform 

The  WINS  NG  2.0  sensor  development  platform  represented  a  significant  upgrade  to  the  1.0 
platform.  The  WINS  NG  2.0  system  leverages  the  development  within  the  1.0  system,  for  example 
the  preprocessor/ processor  architecture  to  separate  real-time  tasks  from  the  processor,  and  includes 
significant  upgrades  such  as:  extensive  networking  improvement  and  scalability  support,  significantly 
enhanced  sensing  resolution  and  capability,  migration  to  the  Linux  OS  with  significantly  expanded 
development  tools,  and  enhanced  hardware  and  software  flexibility  and  capability  of  the 
development  system  and  networked  sensor  nodes.  A  summary  of  the  capabilities  of  the  WINS  NG 
2.0  platform  is  provided  in  the  sub-sections  below. 

The  WINS  (Wireless  Integrated  Network  Sensors)  NG  version  2.0  Platform  provides  a  development 
platform  for  networked  embedded  systems.  The  WINS  NG  platform  is  designed  to  provide  the 
capability  for  1)  monitoring  many  input  sensor  signal  streams,  2)  processing  these  input  streams,  3) 
performing  local  computation  for  physical  event  recognition,  4)  performing  local  computation  and 
processing  for  local  area  wireless  networking,  and  5)  communication  of  messages,  sensor  data,  and 
code.  The  WINS  NG  platform  hosts  the  software  systems  that  support  signal  processing, 
cooperative  event  detection,  novel  networking,  and  other  distributed  computing  capabilities.  The 
WINS  NG  2.0  system  includes  high  performance  analog  sensor  sampling,  sensor  digital  signal 
processing,  a  scalable  dual  channel  spread  spectrum  wireless  network  solution,  a  32 -bit  application 
processor  and  a  POSIX-compHant  operating  system. 

4.1  Adaptive  Node  Platform 

The  WINS  NG  2.0  node  platform  architecture  includes  a  Real  Time  Interface  Processor™^ 
improving  on  the  capabilities  of  the  preprocessor  provided  in  the  WINS  NG  1.0  nodes.  This  device 
supports  high-speed  multi-port  sampling  integrated  with  both  a  high  speed  DSP  and  direct  digital 
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I/O.  The  architecture  also  includes  a  32-bit  Application  Processor  with  RAM,  ROM,  and  flash 
memory.  Digital  I/O  and  GPS  geolocation  capability  is  provided  with  an  attached  active  antenna. 
The  WINS  NG  2.0  wireless  network  interface  includes  an  adaptive  dual  mode  RF  modem  system 
that  enables  a  solution  for  scalable,  multihop  networking  with  spread  spectrum  signaling.  A  block 
diagram  for  the  WINS  NG  2.0  platform  is  shown  in  Figure  24.  Shown  in  Figure  25  is  the  Real  Time 
Interface  Processor  (a)  and  Application  Processor  (b)  printed  circuit  boards. 


Address/Data  Bus 


■ 

Preprocessor 
Bus  Interface 

ADC 

DSP 

Preprocessor 

Figure  24.  Block  diagram  of  the  WINS  NG  2.0  platform 


The  capabilities  of  the  WINS  NG  2.0  node  processor  are  summarized  in  Table  8.  These  capabilities 
represent  an  upgrade  over  the  WINS  NG  1.0  platform,  providing  significantly  more  developer 
flexibility  and  capability. 


Figure  25.  (a)  WINS  NG  2.0  Processor  Core  and  (b)  Sensor  Interface  System 
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Platform  Processor  Core 

Hitachi  SH-4  7751 

Platform  Memory 

16MB  RAM,  16MB  Flash 

32bit  RISC  architecture 

Superscalar  dual  issue  architecture 

Processor 

Architecture 

Low  power  consumption  with  1 .8V  internal,  3.3V  1/ O  bias 

Branch  operations:  folding,  prediction,  conditional  prefetch 

1 6K  data  cache  and  8K  instruction  cache 

Memory  Management  Units  (MMU) 

Floating  Point  Unit  with  Single  and  Double  Precision 

Processor 

Core:  300  MIPS 

Performance 

Floating  Point  Unit:  1.1  GFLOPS 

Processor 

Power  Dissipation 

400  mW 

Table  8:  Processor  specifications  for  the  WINS  NG  2.0  node. 

4.2  Adaptive  Analog  Sensing  and  Signal  Processing  Platform 

The  WINS  NG  2.0  analog  sensor  interfaces  include  high-speed  sampling  interfaces.  This  provides 
high-speed  sampling  up  to  15.5  bit  ENOB  resolution.  The  high-speed  channel  employs  separate 
preamplifiers  and  anti-aliasing  filters  for  each  channel.  Analog  input  sampling  provides  80  ksps  that 
can  be  spread  across  aU  four  channels,  so  that  each  channel  can  be  concurrendy  sampled  at  20  ksps. 
The  specifications  of  the  adaptive  analog  sensing  system  for  the  WINS  NG  2.0  nodes  are  provided  in 
Table  9  and  Table  10. 

The  WINS  NG  2.0  sensor  data  input  stream  operates  at  bandwidth  well  above  the  level  that  is 
practical  for  signal  processing  in  general  purpose  embedded  processors  to  provide  development 
flexibility.  The  sensor  front-end  high-speed  input  sample  rate  is  accommodated  in  a  power-efficient 
approach  with  a  dedicated,  programmable  digital  signal  processor  (DSP);  the  industry  standard  Texas 
Instruments  5402.  This  DSP  is  supplied  with  an  integrated  development  environment.  DSP  code 
may  be  communicated  to  the  platform  via  a  developer  port  or  directly  via  the  wireless  network.  The 
DSP  enables  local  processing  of  high  bandwidth  sensor  data  (up  to  20k  samples/ sec  per  channel 
input).  The  DSP  enables  a  low  power  solution  for  detection  and  identification  of  events  by  the 
sensor  input  suite. 

DSP  software  development  is  straightforward,  using  standard  C-code  compiled  on  Texas 
Instrument's  Code  Composer  Studio  (CCS).  Programming  under  DSP/BIOS,  multiple  processes  can 
be  supported  and  managed  in  real-time  using  API's  supplied  with  CCS.  Hardware  and  software 
interrupts,  along  with  multitasking  services,  mailboxes,  queues,  semaphores,  and  resource  protection, 
can  all  be  viewed  graphically  in  real-time  for  fast  development. 

Industry  standard  tools  support  the  WINS  NG  2.0  DSP  platform.  Tools  and  development  boards 
are  available  to  support  developers  who  are  building  signal  processing  and  event  detection 
capabilities.  In  addition,  design  flexibility  is  provided  on  the  WINS  NG  2.0  system  via  a  sensing  API 
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available  on  the  main  processor,  such  that  initial  development  can  be  conducted  with  standard  Linux 
tools  (compiled  for  the  SH4)  prior  to  porting  code  to  the  TI  DSP. 


High  Speed  S/H  ADC 

4-ch  differential  front-end 

Resolution 

1  Obits* 

Sample  rate 

20kHz 

Selectable  gains 

2,ll,101,1001V/V(6dB,  20.8dB,  40.1dB,  and  6 0.01  dB) 

Selectable  output  word  rates 

20K,  lOK,  5K,  2.5K,1.25K,  625,  312.5, 156.25Hz 

Digital  LP  filtering  and  decimation  for  word  rates  below  20kHz 

Eixed  8th  order  Butterworth  anti-alias 
filter 

-0.2dB  @5kHz 

-3dB  @  6kHz 

-35.5dB@10kHz 

Input  noise  voltage 

15nV/rt(Hz) 

Linearity  metric  to  front-end  (Independent  Linearity  Error) 

Gain  non-linearity 

20ppm** 

ADC  Integral  non-linearity 

Max  ±  6LSB 

*Lower  resolution  at  higher  output  word  rates.  (ENOB  effective  number  of  bits) 
4ch@  20kHz  ENOB=12  bits 

lch@  20kHz  ENOB=13. 5  bits 

Ich  @  1.25kHz  ENOB=15.5  bits 


**  Maximum  deviation  from  best  fit  line 

Table  9:  WINS  NG  2.0  analog-sampling  specifications. 

Processor 

Low  power  digital  signal  processor  control  system 

Frequency  (MHz) 

80 

MIPS 

80 

Data  &  Program  Memory 

16k  internal  128k  external  words  (xl6  bit  addresses  per  word) 

External  memory  shared  between  host  and  DSP 

Arithmetic  and  Logic  Unit 

40-Bit 

Software  System 

Software  implemented  for  sampling  management  only. 
Unprocessed  sensor  data  provided  to  Processor. 

Table  10:  WINS  NG  2.0  adaptive  analog  section  specifications. 
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4.3  Adaptive  RF  Network 


Integrated  within  every  WINS  NG  2.0  node  is  a  dual  mode  RF  modem.  The  modems  provide  the 
basis  for  a  scalable  multi-cluster,  multi-hop  network.  The  dual  mode  approach  solves  the  long¬ 
standing  problem  that  restricts  spread  spectrum  modem  solutions  to  local  cluster/ star  networks.  The 
dual  channel  modem  approach  allows  every  node  to  participate  in  two  networks  simultaneously,  thus 
reducing  latency  In  multi-cluster  communication.  The  two  networks  are  unsynchronized.  However, 
frequency  hopping  reduces  the  likelihood  of  collisions  to  a  negligible  level.  The  dual  mode  modem 
enables  development  of  low  latency  multi-cluster  communication  and  provides  two  overlapping 
independent  sets  of  networks.  Every  node  may  be  configured  as  a  base  or  a  remote  for  each  network. 

The  WINS  NG  2.0  system  operates  in  the  2. 4-2. 4835GHz  ISM  band  transmitting  at  lOOmW  or 
lOmW  on  dual  channels.  Detailed  specifications  on  these  modems  are  included  in  Table  11.  The 
WINS  NG  2.0  platform  is  supplied  with  a  baseline  network  and  RF  modem  configuration.  However, 
additional  flexibility  is  provided  to  enable  developer  system  refinement  for  particular  network 
wireless  applications,  as  they  desire.  In  addition,  the  WINS  NG  nodes  provide  the  expandability  to 
support  802.1 1  PCMICA  cards  as  an  alternative  network  as  discussed  below  in  section  4.4. 

Each  of  the  two  integrated  RF  modems  within  a  WINS  NG  2.0  node  provides  a  peak  air  interface 
rate  of  460  kbps.  However,  the  sustained,  continuous  throughput  is  56  kbps  per  channel  for  two 
channels. 

In  addition  to  the  integrated  RF  modems  and  expansion  support  for  PCMCIA  cards,  such  as 
802.11b,  the  WINS  NG  2.0  system  also  provides  wireline  interfaces  with  both  10  Mb  Ethernet  and 
serial  port  access. 


Frequency 

2.4-2.483GHZ 

Coding 

Frequency  Hopped  Spread  Spectrum  (FHSS) 

FCC  Certification 

FCC  part  15.247,  ETS  300-328  and  RSS210  rules,  license 
free 

Channel  Data  Rate 

56kbps  node  to  node 

#  of  frequency  channels 

75 

Independent  networks 

64  (for  both  modes) 

RF  Bandwidth 

750kHz 

Transmit  power 

lOm  W  or  100m  W 

Outdoor  operating  Range 

25m  worst  case  (zero  elevation,  cluttered,  no  LOS) 

100m  surface-to-surface  LOS 

500+m  elevated  with  line  of  sight 

Indoor  operating  range 

25m-100m 

Table  11:  WINS  NG  2.0  specification  for  each  of  the  two  integrated  RF  modems. 


4.3.1  WINS  NG  2.0  Networking 

The  WINS  (Wireless  Integrated  Network  Sensors)  NG  version  2.0  Platform  provides  a  development 
system  designed  to  facilitate  a  low  latency  multi-hop  network  configuration.  Due  to  the  requirement 
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for  synchronization,  all  available  point  to  multipoint  wireless  systems  currently  operate  in  a  base  and 
remote  or  star  configuration,  as  shown  in  Figure  26.  The  master-slave  or  base-remote  configuration 
ensures  that  multiple  radios  can  talk  to  one  another  by  fixing  the  synchronization  mechanism 
dictated  by  the  base  and  all  its  associated  remotes.  In  order  for  a  node  to  talk  with  any  node  outside 
its  individual  cluster  the  node  must  synchronize  to  a  separate  communication  link  (separate  base  and 
remote  cluster).  In  the  2.0  nodes,  this  is  done  by  enabling  each  node  to  operate  on  two  star  networks 
concurrently  so  that  packets  can  be  routed  quickly  between  clusters  (each  consisting  of  a  base  and  its 
associated  remotes,  as  shown  in  Figure  27).  In  order  to  provide  low  latency  packet  transmission,  the 
dual  network  access  is  provided  with  dedicated  hardware,  rather  than  by  expanding  the  complexity  of 
each  individual  modem.  This  provides  a  robust,  scalable  extension  of  the  single  cluster  architecture 
(a  cluster  corresponding  to  a  synchronized  channel  between  nodes),  with  the  flexibility  to  support  a 
large  development  community.  The  focus  of  the  2.0  platform  is  to  provide  a  usable  baseline 
configuration  in  the  short  term,  while  providing  the  capabilities  for  software  customization  to  meet 
requirements  as  they  arise. 
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Figure  26.  Illustration  of  the  Base  and  Remote  building  block  for  the  network  architecture. 


Figure  27.  Illustration  of  dual  node  networks  showing  all  one-hop  paths  between  bases  and  remotes. 

4.3.1.1  Individual  Modem  Operation 

The  WINS  NG  2.0  node  employs  two  independent  modems  per  node.  Each  of  these  modems 
operates  with  Frequency  Hopped  Spread  Spectrum  (FHSS)  signaling.  The  hopping  is  distributed  over 
75  channels  within  the  2.4GHz  to  2. 4835GHz  worldwide  ISM  band  at  a  hopping  rate  of  once  per 
14.375ms.  Communication  between  base  and  remotes  is  synchronized  within  a  TDMA  cycle  within 
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each  hop.  At  the  beginning  of  a  hop,  the  base  transmits  first  a  synchronkation  signal,  then  any  data 
in  its  buffer,  followed  by  transmissions  in  TDMA  time  slots  from  each  of  the  remotes  synchronized 
by  that  base.  The  number  of  remotes  dictates  the  time  slot  assigned  to  each  remote  and  hence  the 
packet  size  sent,  with  the  transmission  set  up  to  operate  efficiendy  with  up  to  8  remotes.  Larger 
number  of  remotes  per  base  can  be  used.  However,  communication  efficiency  drops  as  the  header 
size  occupies  increasingly  large  portions  of  each  packet.  While  the  base  and  remote  channel  is 
TDMA,  from  the  API  perspective,  the  radios  appear  to  communicate  in  full  duplex  mode  as 
transmitted  and  received  packets  at  a  single  modem  are  interleaved. 

When  a  modem  is  powered  on  and  assigned  to  a  specific  network  as  a  base,  it  acquires  any  remotes 
within  range  on  the  same  channel  that  are  not  already  synchronized  with  another  base.  Similarly,  any 
remotes  that  are  powered  synchronize  with  any  existing  bases  on  their  networks.  Once  every  256 
hops,  each  remote  re-registers  with  the  base,  so  that  if  a  remote  disappears  after  being  in  the 
network,  it  will  be  noticed  within  4s.  Similarly,  if  a  base  disappears,  since  it  sends  out  synchronization 
signals  each  hop,  its  associated  remotes  will  notice  its  disappearance  immediately.  Within  the  2.0 
nodes,  the  modems  appearance  and  disappearance  on  the  wireless  channel  is  provided  through  the 
API  as  connect  or  disconnect  packets  generated  by  each  internal  modem  when  they  are  no  longer 
synchronized  with  a  specific  base  or  remote. 

Within  the  modems,  each  packet  is  sent  with  an  ARQ  scheme  that  retransmits  any  lost  packets  at  the 
physical  layer  up  to  16  times  based  on  a  24bit  checksum.  The  number  of  retransmissions  is 
configurable,  to  modify  communication  as  desired.  However,  the  ARQ  is  only  enabled  for  point-to- 
point  transmissions.  While  every  transmission  from  a  remote  to  its  associated  base  is  point-to-point 
and  hence  uses  the  ARQ  if  configured,  transmissions  from  a  base  to  a  remote  may  be  point-to-point 
(if  a  specific  node  is  addressed)  or  broadcast,  in  which  no  retransmission  is  implemented.  A  one-byte 
checksum  is  also  provided  at  the  driver  layer  that  can  be  utilized  if  error  checking  is  desired  at  higher 
layers.  Additional  feedback  on  the  channel  is  provided  through  the  RSSI  option  of  the  radio  API. 
This  provides  the  power  level  averaged  over  the  last  ten  frequency  hops  seen  by  a  remote.  The  RSSI 
value  is  not  defined  at  a  base,  because  each  base  may  be  communicating  with  multiple  remotes,  while 
each  remote  only  communicates  with  a  single  base.  The  RSSI  value  is  the  ten-hop  average  of  the 
regular  synchronization  header  transmitted  from  the  base  at  the  start  of  each  hop. 

The  power  draw  of  the  RF  modems  is  dependent  on  their  operational  status.  In  the  default  mode  of 
lOOmW  transmit  power,  the  power  cost  associated  with  operating  a  base  (without  transmitting 
anything  other  than  synchronization  packets)  is  420mW,  compared  to  90mW  for  a  modem  to 
operate  as  a  synchronized  remote.  In  addition,  the  cost  to  transmit  data  between  nodes  is 
approximately  20mJ/kbit  at  the  base  side,  and  50mJ/kbit  at  the  remote  side. 

The  2.0  radio  API  provides  access  to  setting  the  operational  status  of  each  modem  (base  or  remote, 
transmit  power,  network,  etc.).  However,  a  default  operational  status  will  also  be  provided  based  on  a 
deterministic  node  lay  out,  as  well  as  based  on  the  autonomous  clustering  described  in  section  4.3.2. 

4.3.1.2  Multi-Hop  Network 

Within  the  WINS  NG  2.0  node,  two  modems  operate  simultaneously;  each  on  an  independent 
network  or  cluster.  The  RF  Modem  API  documents  how  each  of  these  modem  drivers  can  be 
accessed  independently.  The  dual  architecture  facilitates  passing  information  between  clusters  and 
allows  messages  to  be  passed  between  networks.  For  example,  as  illustrated  in  Figure  28,  the  dual 
modem  nature  of  each  node  provides  multiple  paths  between  nodes.  Additionally,  by  transferring 
messages  between  each  modem  driver  on  a  node,  a  message  can  be  passed  over  many  hops;  for 
example,  from  node  1  to  node  8  by  passing  through  nodes  (1 ,2,3,6, 8  i.e.  through  radios  a,c,d,f,k,l,o). 
Since  the  dual  modems  operate  independently,  the  latency  in  message  passing  is  reduced  to  that 
required  to  route  information  between  each  modem  driver.  The  header  of  each  packet  passed  up 
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through  the  radio  API  enables  directed  routing  as  well  as  providing  for  packets  to  be  passed  along  in 
a  broadcast  mode  at  each  step  of  the  process. 


Figure  28.  Illustration  of  three  overlapping  networks.  Node  numbers  are  shown  in  black  with  each  associated 

RF  modem  labeled  with  letters. 


Since  each  node  is  operating  two  independent  modems,  each  node  also  has  two  RF  addresses.  At  the 
RF  modem  API  level,  everything  is  referred  to  the  RF  address.  For  example,  rather  than  labeling  the 
nodes  in  Figure  28  with  node  numbers  1-8,  the  associated  radios  would  be  addressed  by  the  radio 
addresses  a-p  (in  the  figure  radios  b  and  p  are  not  assigned  a  network).  This  provides  flexibility  in 
building  up  a  routing  table  based  on  associated  neighboring  radio  addresses.  The  RF  modem  API 
provides  the  capability  of  returning  all  the  radios  connected  to  a  given  radio.  However,  it  is  not 
specified  which  nodes  those  radios  are  attached  to  at  the  API  level.  The  capability  is  provided  to  pass 
messages  between  the  individual  radios,  to  ascertain  which  nodes  they  are  associated  with,  in  order  to 
build  node  driven  routing  tables.  Additionally,  a  default  network  operation  can  be  downloaded  to 
each  node  for  initial  demonstration  and  experimental  purposes. 

To  alleviate  the  complication  of  adhoc  network  assembly,  each  node  was  initially  provided  with  a 
default  network  and  radio  status,  based  on  a  preconceived  node  lay  down.  Network  assembly  after 
nodes  are  deployed  in  an  adhoc  fashion  is  also  provided  as  described  in  the  following  section.  Thus, 
for  example.  Figure  28  could  provide  a  deterministic  network  for  a  sample  node  layout.  It  is  then 
easily  seen  based  on  the  deterministic  layout  which  radio  IDs  are  associated  with  which  nodes.  This 
also  can  be  used  to  ensure  optimal  connectivity  across  multiple  clusters. 

4.3.2  Automatic  Cluster  Formation 

While  for  some  applications  static  configuration  of  clustering  may  be  the  best  approach,  in  many 
cases  it  is  inconvenient  to  set  up  a  static  configuration.  In  these  cases,  it  may  be  helpful  to  utilize  the 
cluster  formation  module  to  automatically  configure  the  network  parameters  for  a  group  of  nodes. 
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The  clustering  module  operates  through  the  radio  drivers  to  setup  the  communication  network 
autonomously.  This  module  sets  the  RF  modem  parameters  to  form  local  communication  clusters  in 
order  to  ensure  communication  is  possible  across  the  network.  The  RF  modems  operate  in  a  TDMA 
cycle  controlled  by  a  base  unit,  communicating  to  a  number  of  remote  units  as  described  above.  The 
clustering  module  autonomously  determines  which  WINS  NG  2.0  modem  should  act  as  the  cluster 
synchroni2er,  based  on  whom  it  can  directly  communicate.  The  clustering  module  assigns  each 
modem  first  as  a  passive  listener  within  each  cluster  (as  a  remote  to  determine  if  another  node  is 
synchronizing  the  network),  then,  based  on  with  whom  each  modem  can  communicate,  either 
becomes  a  base  to  which  other  nodes  can  synchronize  or  synchronizes  to  another  node  which  has 
become  a  base.  The  clustering  module  listens  for  a  random  period  of  time  for  other  radios  before 
attempting  synchronization,  requires  a  minimum  number  of  other  available  nodes  to  synchronize 
with  (“minimum  number  or  remotes  per  cluster”  option  with  the  current  radios),  and  cycles  between 
listening  and  attempting  synchronization  until  each  cluster  stabilizes. 

The  clustering  module  uses  heartbeats  passed  between  nodes  to  monitor  the  status  of  the  RF  link  in 
order  to  determine  if  it  should  re-assemble  the  network.  In  the  event  of  a  change  in  network 
topology  (one  node  is  turned  off,  or  runs  out  of  energy),  the  network  will  reassemble  with  the 
available  nodes.  The  clustering  module  uses  only  two  frequency-hopping  patterns:  network  5  and 
network  6.  This  streamlines  the  implementation  of  the  autonomous  cluster  formation. 

By  default,  the  clustering  algorithm  will  require  a  minimum  of  one  remote  per  cluster.  Depending  on 
the  type  of  topology  expected,  and  depending  on  application  requirements,  it  may  be  desirable  to 
require  that  clusters  contain  more  than  one  remote.  This  can  be  configured  using  the  -n  option, 
which  enables  the  user  to  force  each  cluster  to  have  at  least  N  remotes.  Table  12  summarizes  the 
options  in  using  clustering  on  the  WINS  NG  2.0  nodes. 


Description 

Option  Syntax 

Default 

Number  of  “Network  A” 

-a  <0-63> 

5 

Number  of  “Network  B” 

-b  <0-63> 

6 

Minimum  number  of  remotes  per  cluster 

-n  <1-10> 

1 

Table  12:  WINS  NG  2.0  autonomous  clustering  options 


4.3.2.1  Recommended  Practices  For  Using  Clustering 

The  WINS  NG  2.0  clustering  is  based  on  a  statistical  connection  between  nodes,  built  up  from  local 
connectivity.  As  a  result,  multi-hop  connectivity  is  not  ensured  for  every  topology.  However,  simple 
practices  can  be  utilized  to  improve  the  connectivity  for  a  WINS  NG  2.0  node  lay  out. 

The  most  limited  RF  communication  will  generally  occur  for  WINS  NG  2.0  nodes  when  they  are 
placed  in  indoor  settings  and  when  they  are  placed  outdoors  on  the  ground.  In  both  cases,  RF 
propagation  can  be  modeled,  to  the  first  order,  with  a  fourth-order  power  fall  off  with  distance, 
giving  a  worst-case  maximum  range  between  base  and  remote  nodes  of  30  to  50m.  In  a  number  of 
environments  this  maximum  range  will  be  much  greater  (up  to  4km  in  line  of  sight  conditions). 
However,  the  30m  to  50m  range  provides  a  baseline  link  distance. 

In  order  for  clustering  to  effectively  connect  nodes  with  a  stable  link,  enough  possible  connections 
between  nodes  must  be  available  at  less  than  the  maximum  range.  In  addition,  use  of  the  “minimum 
number  of  remotes”  option  can  decrease  the  fraction  of  nodes  operating  as  bases,  changing  node 
interconnectivity.  As  a  general  rule,  node  spacing  of  25m  or  less  with  nodes  distributed  over  an  area 
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(as  opposed  to  in  a  line)  will  fuUy  connect  with  the  supplied  clustering  algorithm.  If  the  nodes  are 
deployed  in  a  single  line,  increasing  the  antenna  heights,  reducing  the  inter-node  spacing,  and 
increasing  the  minimum  number  of  remotes  option  to  two  will  all  improve  the  stability  and  inter¬ 
connectivity  of  the  network.  The  default  minimum  number  of  remotes  set  at  one  enables  cluster 
formation  with  only  two  WINS  NG  nodes,  as  well  as  provides  effective  clustering  for  well  separated 
nodes  evenly  distributed  over  an  area. 

4.3.3  The  Sensoria  Visualization  Tool  used  with  WINS  NG  2.0 

The  Sensoria  Visualization  Tool  GUI  provides  detailed  feedback  for  debugging  problems  with  the 
network  in  moving  from  simulation  to  actual  deployment.  A  screen  capture  of  the  GUI  is  shown  in 
Figure  29.  As  shown  in  the  figure,  each  node  with  Ethernet  connections  (130,  135,  and  129)  displays 
the  base/remote  status  of  its  radios  (bases  are  either  blue  or  red  boxes;  remotes  are  white  boxes), 
displays  the  RSSI  value  seen  by  each  remote,  and  provides  lines  indicating  if  one-way  or  two-way 
communication  is  currently  available  (the  red  and  blue  arrows).  In  the  figure,  it  can  be  seen  that 
nodes  130  and  133  are  bases,  although  133  is  not  shown  as  blue  since  it  is  not  connected  via 
Ethernet.  In  addition,  not  shown  in  this  screen  shot,  the  Sensoria  Visualization  tool  also  displays  the 
timer  values  in  the  clustering  algorithm  described  in  the  previous  sub-section  for  each  radio  (on 
nodes  connected  over  Ethernet)  to  illustrate  whether  the  network  has  stabilized  or  is  sdU  forming. 
Since  all  information  for  the  visualization  tool  is  obtained  over  Ethernet  connections,  the  monitoring 
of  the  RF  network  does  not  impact  its  performance.  However,  due  to  this  restriction,  RSSI  and  timer 
information  can  only  be  obtained  for  nodes  to  which  there  is  an  Ethernet  connection,  and  network 
connectivity  is  only  based  on  connectivity  information  gathered  from  Ethernet-connected  nodes. 
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4.4  802.11b  Wireless  Network  Interface  Setup  for  WINS  NG  2.0 
Nodes 

A  WINS  NG  2.0  may  be  configured  to  operate  using  a  number  of  different  RF  communication 
options.  An  alternative  to  using  the  embedded  RF  modems  for  wireless  communication  is  to  equip 
a  WINS  NG  2.0  with  one  or  two  PCMCIA  802.1  lb  cards. 

Any  standard  802.11b  card  that  is  supported  under  Linux  is  expected  to  be  compatible  with  this 
build,  if  operated  in  infrastructure  modef  However,  in  most  multihop  applications,  these  cards  need 
to  be  operated  in  ad  hoc  mode. 

4.5  WINS  NG  2.0  Software  Development  Environment 

The  WINS  NG  2.0  system  provides  both  a  hardware  platform  and  software  APIs.  Node 
development  may  be  conducted  through  the  node  Ethernet  port  or  an  RS232  diagnostic  port. 

The  WINS  NG  2.0  platform  supports  the  Linux  operating  system  with  the  2.4  kernel  version. 
Services  including  a  ramdisk,  flashfile  system,  Ethernet  networking,  NFS  file  access,  and 
development  compiler  and  debugger  tools  have  been  developed  and  are  supplied. 

A  large  set  of  Linux  packages  have  also  been  installed  and  tested,  and  these  include  packages  for  both 
the  development  platform  and  the  WINS  NG  2.0  node,  enabling  an  array  of  developer  support  on 
this  embedded  platform. 

For  the  development  platform  (which  can  be  a  normal  x86  PC),  the  packages  and  their  applications 
include: 

1)  binutils 

a)  Basic  utilities  including  linker  and  profiler 

2)  crackHb 

a)  Tests  passwords  to  determine  whether  they  match  certain  security-oriented  characteristics 

3)  gkbc 

a)  GNU  C-library 

4)  kbtermcap 

a)  Basic  system  library  needed  to  access  the  termcap  database.  The  termcap  library  supports 
easy  access  to  the  termcap  database,  so  that  programs  can  output  character-based  displays  in 
a  terminal-independent  manner. 

5)  ncurses 

a)  Clone  of  System  V  Release  4.0  (SVr4)  "cursor  optimization".  Library  of  functions  that 
manage  an  application's  display  on  character-cell  terminals  (e.g.,  VTIOO). 

6)  openssl 

a)  Secure  sockets  layer 

7)  pam 

a)  Security  tool  for  authentication  of  SMB  file  access 


*  For  definition  of  terms  for  wireless  LAN  operation  please  refer  to  IEEE  802.1 1  standards  documents. 
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8)  popt 

a)  C  library  for  parsing  command  line  parameters 

9)  pwdb 

a)  password  database  library 

10)  slang 

a)  S-Lang  extension  language  static  libraries  and  header  files.  S-lang  is  a  C-like  screen-handling 
language. 

11)  tcl 

a)  TCL  scripting  language 

12)  tcp_wrappers 

a)  Access  control 

13)  zkb 

a)  Data  compression 

For  the  WINS  NG  2.0  node,  the  packages  and  their  applications  include: 

1)  SysVinit 

a)  SysVinit  includes  the  init  program,  the  first  program  started  by  the  Linux  kernel  when  the 
system  boots.  Init  then  controls  the  startup,  running,  and  shutdown  of  all  other  programs. 

2)  bash2 

a)  Shell 

3)  bzip2 

a)  File  compression 

4)  e2fsprogs 

a)  Utilities  for  managing  the  second  extended  (ext2)  filesystem 

5)  fileutils 

a)  Basic  directory 

6)  ftp 

a)  File  transfer 

7)  gkbc 

a)  C  library 

8)  gzip 

a)  File  compression 

9)  inetd 

a)  The  inetd  package  contains  the  inetd  networking  program.  Inetd  listens  on  certain  Internet 
sockets  for  connection  requests,  decides  what  program  should  receive  each  request,  and 
starts  that  program. 

10)  initscripts 

a)  The  initscripts  package  contains  the  basic  system  scripts  used  to  boot,  change  run  levels,  and 
shut  the  system  down  cleanly.  Initscripts  also  contains  the  scripts  that  activate  and  deactivate 
most  network  interfaces. 
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11)  mingetty 

a)  Opens  tty  lines  and  sets  their  modes,  prints  the  login  prompt,  and  gets  the  user  name  to 
initiate  a  login  process  for  the  user. 

12)  mktemp 

a)  The  mktemp  utility  takes  a  given  file  name  template  and  overwrites  a  portion  of  it  to  create  a 
unique  file  name.  This  allows  shell  scripts  and  other  programs  to  safely  create  and  use  / tmp 
files. 

13)  modutils 

a)  The  Linux  kernel  allows  new  kernel  pieces  to  be  loaded  and  old  ones  to  be  unloaded  while 
the  kernel  continues  to  run.  These  loadable  pieces  are  called  modules,  and  can  include  device 
drivers  and  filesystems  among  other  things.  This  package  includes  program  to  load  and 
unload  programs  both  automatically  and  manually. 

14)  net- tools 

a)  This  is  a  collection  of  the  basic  tools  necessary  for  setting  up  networking  on  a  Linux 
machine.  It  includes  ifconfig,  route,  netstat,  rarp,  and  some  other  minor  tools. 

15)  ntsysv 

a)  ntsysv  provides  a  full-screen  tool  for  updating  the  / etc/ rc.d  directory  hierarchy,  which 
controls  the  starting  and  stopping  of  system  services. 

16)  passwd 

a)  Password  services 

17)  setserial 

a)  Set  serial  port  configuration 

18)  sh-utils 

a)  Shell  scripting  utilities 


Utilities  used  in  typical  shell  scripts 

19)  sysklogd 

a)  The  sysklogd  package  contains  two  system  utilities  (syslogd  and  klogd)  which  provide 
support  for  system  logging.  Syslogd  and  klogd  run  as  daemons  (background  processes)  and 
log  system  messages  to  different  places,  (sendmail  logs,  security  logs,  error  logs,  etc.). 

20)  file  archiving 
a)  telnetd 

21)  Telnet  daemon 
a)  util-Hnux 

22)  zkb 

a)  Compression 


4.6  Power  Specifications 

To  support  the  development  community,  each  WINS  NG  2.0  node  has  been  supplied  with  a  lead 
acid  battery,  which  can  supply  power  to  the  nodes.  The  characteristics  of  this  battery  platform  are 
shown  in  Table  13.  In  addition,  each  of  these  battery  packages  can  be  configured  to  supply  double 
density,  effectively  doubling  the  lifetime  figures  of  Table  13. 
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Battery  Lifetime 

3  hour  continuous  use 

20  hour  standby  operation 

Battery  charging  time 

5  hours  from  uncharged 

Adapter 

120V  60Hz  to  12V DC  in 

Table  13:  Operational  lifetime  of  the  WINS  NG  2.0  nodes  using  its  supplied  battery. 


4.7  GPS  Technical  Specifications 

As  in  the  WINS  NG  1.0  nodes,  the  WINS  NG  2.0  nodes  include  an  integrated  GPS  receiver  and 
active  GPS  antenna,  with  a  six-foot  cable  to  provide  flexibility  in  GPS  antenna  placement.  Specifics 
of  the  GPS  receiver  in  the  WINS  NG  2.0  nodes  are  shown  in  Table  14. 


Received  codes: 

LI,  C/A  code 

Channels 

12 

Max  Solution  update 

10/s  (1/s  standard) 

Satellite  Reacquisition  Time 

100ms 

Snap  Start 

<  2  seconds 

Hot  Start 

<  8  seconds  average 

Warm  Start 

<38  seconds  average 

Cold  Start 

<  45  seconds  average 

Minimum  signal  tracked 

-1 75  dBm 

Maximum  altitude 

<  60,000 feet 

Maximum  velocity 

<  1000  knots 

Protocols 

NMEA  v2.2 

Position  Accuracy 

10  meter  2dRMS,  WAAS  enabled 

1-5  meter,  DGPS  corrected 

GPS  antenna  cable  length 

6  feet 

Table  14:  Specifications  for  the  GPS  system  included  with  the  WINS  NG  2.0  nodes. 

4.8  WINS  Imager  2.0 

The  WINS  NG  program  has  been  very  successful  with  the  development  of  the  WINS  NG  2.0  node 
that  dramatically  exceeds  the  performance  and  development  support  capabilities  of  any  other 
available  contemporary  wireless  embedded  systems  technology.  WINS  NG  2.0  has  been  designed 
and  implemented  to  support  the  SensIT  program  that  includes  requirements  for  a  highly  capable, 
multiple  network  port,  low  power,  standalone  embedded  wireless  system.  It  includes  wireless 
networking,  analog  sensing,  an  open  operating  system,  and  infrastructure  API  software.  In  addition. 
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the  SensIT  community  requested  Sensoria  Corporation,  to  provide  an  Imager  that  cleanly  interfaces 
with  the  WINS  NG  2.0  network.  This  Imager  provides  “eyes  on  target”  when  triggered  by  lower 
energy  sensors,  as  the  final  point  in  an  automated  sensing  hierarchy,  when  a  notification  of  an  event 
is  passed  up  out  of  the  network.  A  picture  of  this  WINS  2.0  Imager  is  shown  in  Figure  30  atop  a 
WINS  NG  2.0  battery  pack. 


Figure  30.  WINS  2.0  Imager  atop  a  battery  pack. 


The  WINS  2.0  Imager  provides  support  for  demonstrations  of  algorithms  developed  within  the 
SensIT  program  operating  on  the  WINS  NG  2.0  Sensor  Platform.  As  such,  it  interfaces  to  the  WINS 
NG  2.0  network  described  above,  provides  the  same  functionality  as  a  WINS  NG  2.0  node,  and 
provides  an  API  documenting  the  features  of  the  Imager  available  to  processes  running  on  the 
sensor  nodes  to  capture,  modify,  and  transport  acquired  pictures. 

The  WINS  2.0  Imager  nodes  support  all  the  capabilities  of  the  WINS  NG  2.0  nodes  (dual  radio 
architecture,  sensing,  GPS,  operating  system,  and  hardware),  in  addition  to  containing  imaging 
hardware  and  an  interface  to  imaging  functions,  including  triggering  the  nodes  at  predetermined 
times  and  sending  the  acquired  pictures  over  the  RF  network. 

The  WINS  2.0  Imager  builds  on  Sensoria  Corporation’s  experience  in  providing  a  prior  version  of 
Imager  to  support  demonstrations  on  the  WINS  NG  1.0  sensor  nodes  as  described  in  section  3.5. 
Details  of  the  improvements  incorporated  into  the  2.0  Imager  are  provided  in  the  next  section. 

4.8.1  Improvements  over  the  Prior  Sensoria  WINS  Imager 

The  WINS  2.0  Imager  represents  a  substantial  improvement  over  the  prior  version  of  the  Sensoria 
Imager  developed  outside  of  the  SensIT  program.  The  prior  Imager  was  designed  to  meet  the 
requirements  of  a  TRSS  sensor  network,  where  local  sensors  supplied  the  impetus  to  trigger  the 
Imager,  and  then  refined  in  the  early  stages  of  the  WINS  NG  program.  As  part  of  this  prior  effort,  a 
single  prototype  imager  was  constructed  with  a  dedicated  point-to-point  radio  link  to  pass  a  picture 
to  a  remote  observer.  The  WINS  2.0  Imager  provides  the  flexibility  not  provided  by  the  prior  WINS 
1.0  Sensoria  Imager.  It  interfaces  directly  with  a  WINS  NG  2.0  node  to  provide  a  mechanism  for 
power  control  (power  savings),  to  enable  local  processing  on  a  2.0  node  or  passing  along  the  image 
over  the  WINS  NG  2.0  radio  network,  to  reduce  the  latency  in  image  acquisition,  and  provide  more 
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flexibility  as  to  how  many  pictures  of  what  resolution  are  taken.  In  addition,  as  only  a  single  prior 
imager  was  developed,  the  WINS  2.0  Imager  development  optimized  the  Imager  system  to  support 
the  SensIT  program,  by  leveraging  current  COTS  imaging  components  for  increased  performance 
and  providing  multiple  imagers  to  support  demonstrations  to  reduce  the  probability  of  a  hardware 
component  failure  compromising  future  demonstrations.  The  WINS  2.0  Imager  architecture  is 
outlined  in  the  next  section. 

4.8.2  The  WINS  2.0  Imager  Architecture 

The  WINS  2.0  Imager  is  integrated  with  the  WINS  NG  2.0  platform  such  that  a  WINS  NG  2.0 
imager  may  acquire  an  image  upon  command  and  recover  this  image  into  the  WINS  NG  2.0  file 
system.  At  this  point,  the  image  is  available  to  be  transported  over  Ethernet  or  the  WINS  NG 
wireless  network.  The  WINS  2.0  Imager  is  also  compatible  with  WINS  NG  2.0  power  systems,  and 
leverages  a  WINS  NG  2.0  node  to  provide  power  saving  capability;  i.e.  the  attached  WINS  NG  2.0 
node  can  power  up  and  power  down  the  imaging  sub-system  as  needed. 

Figure  31  describes  the  integrated  WINS  Imager  and  node  architecture.  The  WINS  2.0  Imager 
imaging  sub-system  is  packaged  into  a  WINS  NG  2.0  node  and  connects  to  the  processor  via  an 
Ethernet  1 00MB  link,  while  providing  an  external  Ethernet  port  as  on  the  current  WINS  NG  2.0 
nodes.  This  architecture  enables  the  Imager  to  be  separately  controlled  as  an  independent  module  of 
the  2.0  node,  while  sharing  the  same  battery  and  providing  a  high  speed  interface  for  transferring 
pictures  from  the  Digital  Imager  to  the  node’s  SH4  processor.  In  addition,  this  layer  of  separation 
allows  Sensoria  Corporation  to  leverage  the  resources  in  the  open  source  community  for 
coordinating  timing  on  the  CMOS  digital  Imager,  over  the  imager  interface,  to  ensure  low  latency 
picture  acquisition.  Specifications  for  the  WINS  2.0  Imager  are  provided  in  Table  15. 


Image 

640x480  CMOS  digital  imager 

24-bit  color  or  8-bit  monochrome 

I  frame  per  2s 

Imager  Interface 

lO/IOOMbps 

telnet,  ftp,  TCP,  IP,  and  UDP  clients 

CMOS  Digital  Imager  power  control 

Features 

variable  Compression  ratio 

variable  exposure  time  with  auto  focus 

text  overlay 

Table  15:  WINS  2.0  Imager  specifications. 
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Figure  31.  WINS  2.0  Imager  architecture. 


The  WINS  NG  2.0  Imager  includes  an  API  that  provides  access  to  the  Imager  capabilities  from  the 
standard  WINS  NG  2.0  platform.  This  API  support  calls  across  the  Ethernet  connection  and 
includes: 

•  A  command  to  trigger  the  imager  at  a  set  time.  This  may  include  a  single  picture  or  sequence 
of  pictures.  Incorporated  in  this  command  is  a  transfer  of  acquired  images  to  the  WINS  NG 
2.0  node  processor. 

•  Power  Control  of  the  Imager.  This  includes  power  up  and  power  down  features  to  conserve 
energy.  Thus,  the  CMOS  digital  imager  may  only  be  powered  up  when  images  are  desired. 

•  Optional  access  to  image  control  features  such  as  exposure  time,  image  compression,  and 
text  overlay. 

All  API  commands  are  supported  on  the  Linux  OS  running  on  the  WINS  NG  2.0  nodes. 

4.8.3  Steel  Knight  WINS  Deployment  Status  Report 

The  WINS  Imagers  were  deployed  at  the  Sensor  site  shown  in  Figure  32  as  part  of  the  Steel  Knight 
combined  arms  exercise  at  the  MCAGCC  at  29  Palms  in  December  2001.  The  Imagers  are 
designated  as  1  and  3  in  this  image.  The  locations  of  the  OP  Kumar  relay  site  and  the  Command  and 
Operations  Center  (COC)  are  shown.  The  network  architecture  to  provide  pictures  from  the 
remotely  deployed  imagers  of  all  vehicles  passing  on  an  access  road  is  shown  in  Figure  33. 

In  conjunction  with  the  WINS  2.0  Imager  node,  the  Steel  knight  deployment  also  utilized  a  long 
range  802.11b  link  setup  by  BBN,  as  illustrated  in  Figure  33,  to  provide  a  link  from  both  Imagers  to 
the  COC,  and  a  web  interface  operating  on  a  laptop  at  the  COC.  The  capabilities  of  that  web 
interface  developed  by  Sensoria  Corporation  are  illustrated  in  the  following  sub-sections,  each 
describing  a  webpage  of  that  interface. 
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Figure  32.  Steel  Knight  deployment  aerial  view 


Option: 

Ethernet  cable 
Or  IEEE-802.11 


Figure  33.  Steel  Knight  network  architecture 


4.8.3.1  Imager  Current  Data  Page 

The  WINS  Imager  2.0  Current  Data  page  shows  the  view  of  Figure  34.  The  user  can  click  on  an 
image  to  obtain  a  full  size  image  and  then  scroll  through  any  of  the  full  size  images.  At  each 
acquisition  event,  a  snapshot  of  the  data  collected  via  two  infrared  sensors,  an  acoustic  and  a  seismic 
sensor  are  shown,  along  with  a  sequence  of  five  pictures  snapped  at  Is  intervals  around  the 
acquisition  trigger. 
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Figure  34.  WINS  Imager  2.0  Current  Data  Page. 


Five  images  are  shown  in  the  browser  view  of  Figure  34.  The  five  images  are  captured  in  a  time 
sequence,  with  each  image  separated  by  1  second  in  time.  Two  images  are  acquired  prior  to  the 
trigger  event,  one  at  the  time  of  the  trigger,  and  two  images  are  acquired  after  the  trigger  event.  To 
support  this  operation,  each  imager  camera  is  constandy  buffering  images,  although  only  those 
associated  with  an  event  are  passed  onto  the  web  server. 

4.8.3.2  Image  Triggering 

Image  triggering  is  derived  from  two  passive  infrared  sensors.  The  imagers  are  trained  to  collect  an 
angle  of  view  crossing  the  road  with  both  imagers  located  at  the  same  separation  from  the  road  near 
a  point  on  a  berm  adjacent  to  the  road.  Imager  1  is  adjacent  to  Imager  2.  For  the  Steel  Knight  setup, 
the  Imager  1  and  Imager  2  viewing  angles  differed  by  about  30  degrees.  The  angle  bisecting  their 
viewing  angles  is  perpendicular  to  the  road.  The  arrangement  is  shown  in  Figure  35. 

The  two  passive  IR  sensors,  sampling  detection  beams  facing  slightly  northwesterly  and 
southeasterly,  detect  north-  and  south-bound  vehicles  and  personnel,  respectively,  and  are  used  to 
trigger  image  transfer  to  the  Webserver.  Either  the  north  or  south  bound  sensor  will  trigger  an  image. 
The  data  trace  associated  with  the  sensor  that  initiated  a  trigger  will  be  shown  in  a  red  color.  All 
others  will  be  blue,  as  seen  in  Figure  34. 
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Figure  35.  Imager  1  and  2  deployment  at  a  berm  near  road.  The  Imager  locations  are  indicated  by  the  black 
rectangles  and  the  Imager  viewing  angles  are  indicated  by  the  arrows. 

4.8.3.3  Image  History  Page 

The  WINS  Imager  Image  History  page  can  be  reached  from  any  of  the  Imager  web  interface  pages 
from  the  icon  seen  in  the  upper  right  corner  of  each  web  page.  This  page  allows  the  user  to  enter  a 
time  and  date  range  and  launch  a  database  query  to  recover  the  images  acquired  during  these  times.  A 
sample  of  the  Image  History  page  is  shown  in  Figure  36. 
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Figure  36.  View  of  the  WINS  Imager  2.0  History  Page. 
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4.8.3.4  Alarm  Window  Page 

An  alarm  function  is  constantly  vigilant  at  the  browser  to  enable  an  alarm  indication  for  the  user. 
This  functionality  produces  a  pop-up  window  that  appears  when  either  Imager  1  or  Imager  2  detect 
an  event.  The  alarm  function  is  implemented  as  a  Java  applet  and  Java  script  and  will  operate  without 
requirement  for  installation  of  software  on  the  machine  hosting  the  browser. 

This  alarm  function  allows  the  user  to  turn  attention  to  other  tasks  and  when  an  alarm  occurs,  the 
user  is  notified.  The  alarm  pages,  shown  in  Figure  37  and  Figure  38,  indicate  the  location  and 
viewing  angles  of  the  imagers  and  the  COC.  Note  that  the  system  is  setup  to  enable  future 
improvements  so  that  many  imager  locations  may  be  triggered  and  viewed  in  this  way,  providing  the 
user  with  immediate  notification. 


Figure  37.  Alarm  Page  pop-up  window  graphic  indicating  alarm  state  for  Imager  1. 


Figure  38.  Alarm  Page  pop-up  window  graphic  indicating  alarm  state  for  Imager  2. 
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4.8.3.5  WINS  Imager  Deployment  Images 

To  provide  an  idea  of  the  deployment  of  the  WINS  Imager  2.0  system  at  Steel  Knight,  a  view  from 
the  relay  point  (used  to  enable  802.11b  access)  down  to  the  COC  is  shown  in  Figure  39,  with  the 
corresponding  view  from  the  relay  point  to  the  location  of  the  imagers  in  Figure  40. 


Figure  39.  View  of  COC  area  from  OP  Kumar 
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Figure  40.  View  from  OP  Kumar  towards  Sensor  Site.  Dust  from  vehicle  passage  is  observed  on  the  roads. 

4.8.3.6  WINS  Imager  2.0  Deployment  at  Steel  Knight  Overview 

This  section  provides  a  survey  of  the  images  in  the  Steel  Knight  COC  Server  database.  These  were 
acquired  during  the  Steel  Knight  exercise  period. 

The  database  of  images  collected  at  Steel  Knight  was  browsed  to  select  representative  images.  They 
were  selected  for  images  that  in  particular,  show  both  interesting  vehicles  and  events  where  the 
advantages  of  multiple  image  views,  multiple  image  times,  and  multiple  Image  angles  provide  tactical 
value.  These  images  are  shown  below. 

For  example.  Figure  41  through  Figure  47  show  the  value  of  multiple  angles  and  image  backgrounds. 
Also,  it  is  clear  here  that  the  Image  provides  information  on  the  weapons  being  carried  by  a  vehicle. 

Figure  48  through  Figure  50  show  the  value  of  an  image  sequence,  revealing  details  of  a  long  vehicle 
and  trailer. 
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Figure  41.  Imager  1  captures  HMMWV  with  automatic  weapon  in  time  sequence  image  pair.  Note  that  image 
sequence  offers  two  viewing  angles  and  backgrounds,  rendering  the  weapon  more  visible  in  the  second  image. 

(From  6  Dec  2001  image  database.) 


Figure  42.  Imager  2  captures  HMMWV  with  automatic  weapon  (as  shown  in  Figure  41).  Note  that  this 
provides  another  set  of  angular  views  and  backgrounds.  (From  6  Dec  2001  image  database.) 
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Figure  43.  Imager  1  captures  AAV.  (From  6  Dec  2001  image  database.) 


Figure  44.  Imager  2  captures  AAV  of  Figure  43.  (From  6  Dec  2001  image  database.) 
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Figure  45.  Imager  1  sequence  showing  HMMVW  with  automatic  weapon.  (From  6  Dec  2001  image 

database.) 


Figure  46.  Imager  2  sequence  showing  HMMVW  with  automatic  weapon.  (From  6  Dec  2001  image 

database.) 
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Figure  47.  Imager  2  and  Imager  1  capture  an  LAV  passage  at  13:31  on  5  Dec. 
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Figure  48.  M925  5-Ton  in  first  of  an  Imager  1  sequence.  (From  6  Dec  2001  image  database.) 


Figure  49.  M925  5-Ton  in  second  of  an  Imager  1  sequence  —  note  vehicle  is  towing  howit2er. 
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Figure  50.  M925  5-Ton  in  third  of  an  Imager  1  sequence  —  note  view  of  howit2er. 


4.9  Additional  WINS  NG  2.0  Deployments 

The  WINS  Imager  deployment  at  Steel  Knight  represented  one  of  many  deployments  of  the  WINS 
NG  2.0  sensor  systems  during  the  SensIT  program.  In  addition,  more  than  70  nodes  were  setup  at 
the  MCAGCC  at  29  Palms  for  two  weeks  in  November  of  2001,  both  for  data  collection  and  to  test 
software  implementations  and  algorithms  on  the  nodes.  This  test  was  an  expanded  version  of  that 
discussed  in  section  3.4.  An  illustration  of  the  layout  for  75  WINS  NG  2.0  nodes  at  SITEX02  is 
shown  in  Figure  52,  with  a  picture  of  an  individual  node  deployed  at  SITEX02  shown  in  Figure  51. 


Figure  51.  WINS  NG  2.0  node  deployed  at  SITEX02.  The  large  pole  with  caution  tape  was  used  to 
mark  the  location  of  the  node  to  prevent  it  being  run  over. 
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Figure  52.  Node  layout,  aerial  map,  and  overview  of  the  SITEX02  Experiment  using  70+  WINS  NG  2.0 

nodes. 


In  addition  to  deployment  at  SITEX02,  the  SensIT  and  NRL  SRSS  communities,  to  support  their 
wireless  sensor  network  research,  used  over  120  WINS  NG  2.0  nodes.  For  example,  to  complete  the 
SensIT  program,  three  testbeds  of  WINS  NG  2.0  nodes  were  setup  at  BBN’s  Cambridge  facility, 
BAE’s  Austin  facility,  and  PARC’s  Palo  Alto  facility.  Concurrent  demonstrations  were  presented  via 
the  internet  at  the  final  SensIT  PI  meeting.  The  flexibility  and  cross  between  an  embedded  physically 
constrained  and  development  enabling  wireless  sensor  network  system  of  the  WINS  NG  2.0  system 
has  been  thoroughly  demonstrated  in  these  large  sets  of  tests.  In  addition,  significant  feedback  and 
further  work  by  Sensoria  Corporation,  within  the  WINS  NG  program,  has  been  used  to  contribute 
to  the  design  of  our  next  generation  WINS  NG  3.0  sensor  system  described  in  section  6. 

5  Sensoria  Networking  for  NRL  SRSS 

In  addition  to  the  support  of  the  SensIT  community  within  the  WINS  NG  program,  Sensoria 
Corporation  has  also  supplied  WINS  NG  2.0  nodes  and  design  improvements  on  those  nodes  to 
support  the  NRL  SRSS  program.  This  support  has  included  the  delivery  of  three  WINS  NG  2.0 
development  nodes  and  integrated  software  suite  to  NRL,  support  of  these  delivered  nodes,  an  in 
progress  investigation  of  the  current  capabilities  of  Ultrawideband  (UWB)  radio  suppliers  including 
the  maturity  of  their  solutions  and  feasibility  for  integration  into  WINS  systems,  and  development  of 
a  prototype  radio  driver  for  IP  connectivity  via  an  arbitrary  wireless  interface.  Further  detail  on  the 
prototype  radio  driver  investigation  is  provided  below. 
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5.1  Initial  Prototype  for  IP  Connectivity  over  Arbitrary  Wireless 
Interfaces 

The  initial  architecture  for  the  universal  IP  capable  driver  effort  has  been  developed  for  use  of 
arbitrary  radio  systems  within  WINS  NG  nodes.  A  number  of  constraints  and  requirements  have 
been  taken  into  account  in  driving  the  design  process.  These  include: 

•  Use  user  space  processes  as  building  blocks  of  the  overall  driver  architecture  as  much  as 
possible.  This  will  allow  minimal  amounts  of  modification  to  the  Linux  kernel  initially  on 
the  WINS  NG  2.0  and  3.0  nodes. 

•  The  driver  is  comprised  of  two  distinct  portions:  the  upper  section,  that  will  be  hardware 
independent,  and  the  lower  section,  that  is  specific  to  the  type  of  radio  modem  used. 

•  The  driver  architecture  will  provide  a  control  and  management  Interface  similar  to  that  of 
“ifconfig”.  (The  wireless  modem  will  appear  as  another  “network”  interface  to  the  system.) 

The  initial  approach  for  connecting  the  IP  stack  inside  a  Linux  based  environment  is  to  yank/inject 
IP  frames  from/ to  the  kernel.  These  IP  frames  are  effectively  complete  IP  packets  that  have  been 
formed  by  the  stack  inside  the  kernel.  The  frames  are  then  brought  up  to  the  user  space  by  means  of 
the  tun/ tap  kernel  modules. 

A  user  space  process(es)  then  provides  an  “RF  adaptation”  layer.  This  RF  adaptation  layer  performs 
the  following  tasks: 

•  Direct  the  packet  to  the  correct  local  radio  interface. 

•  Perform  packet  segmentation  and  reassembly. 

•  Retrieve  over  the  air  incoming  packets  and  feed  them  to  the  kernel  for  processing  by  the 
stack. 

The  diagram  of  Figure  53  depicts  this  idea. 


Figure  53.  The  layout  of  the  preliminary  driver  architecture  for  universal  wireless  IP  networking. 
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6  WINS  NG  3.0  Research 

The  WINS  3.0  system  is  a  next-generation  modular  embedded  platform.  It  has  been  designed  to 
meet  the  application  requirements  of  a  wide  range  of  UGS  applications,  leveraging  our  experience 
with  the  WINS  NG  1.0,  2.0,  and  prior  systems.  The  3.0  platform  design  supports  very  low-power 
operation  and  is  fully  modular.  This  platform  consists  of  a  number  of  modules,  including  those 
shown  in  the  sample  module  stack  in  Figure  54. 

In  the  system  configuration  shown  in  Figure  54,  a  processor  module,  equipped  with  a  400  MHz  Intel 
PXA250  processor,  32  MB  of  flash  memory,  and  64  MB  of  SDRAM,  is  the  main  system  processor. 
This  module  has  a  number  of  integrated  interfaces,  including  serial  ports  and  analog  inputs  and 
outputs.  The  expansion  module  provides  further  interface  capabilities,  including  additional  serial 
ports  and  an  Ethernet  port,  an  embedded  GPS  module,  and  the  system  power  supply  and  battery 
charger. 


Processor  Module 

P 

DSP  Module 

Expansion  Module 

- 

- 

Analog  Interface  Module 

PCI  Module 

L 

Radio  Module 

Figure  54.  Example  of  a  system  module  stack 

Consistent  with  the  Preprocessor  in  prior  WINS  platforms,  the  WINS  3.0  DSP  module,  based 
around  a  160-MIPS  TI  DSP,  is  dedicated  to  handling  all  hard  real-time  tasks  in  the  system,  allowing 
the  main  system  processor  to  operate  unencumbered  by  harsh  timing  requirements.  The  DSP 
module  is  capable  of  processing  data  acquired  through  the  analog  interface  and,  acting  as  a  system 
bus  master,  can  transfer  the  data  to  the  main  system  processor. 

The  platform  is  capable  of  supporting  up  to  16  independent  analog  input  channels,  each  with  a 
dedicated  24-bit  ADC.  The  converters  are  preceded  by  variable-gain  amplification  and  signal 
conditioning  stages  that  are  optimized  for  interfacing  to  geophones  and  microphones. 

The  system  is  radio  agnostic,  with  interfaces  for  a  variety  of  radio  modules.  With  the  radio  interface 
module,  radios  with  serial,  PCI,  and  miniPCI  interfaces  can  be  supported,  with  dual  radio  module 
interfaces  available  for  most  interface  types. 

The  PCI  interface  available  on  the  PCI  module  allows  easy  expansion  of  the  system  with  COTS 
components.  CF  and  PCMCIA/ CardBus  slots  are  incorporated  into  the  module  for  further  addition 
of  storage  and  interface  resources  to  the  system.  Although  PCI  is  not  a  low-power  interface  solution, 
it  carries  the  advantage  of  being  very  common,  allowing  many  functions  to  be  added  rapidly  to 
systems  using  it  as  the  interface.  With  the  modular  nature  of  the  system,  the  PCI  interface  can  be 
removed  if  not  needed  to  reduce  system  power  consumption. 

Low-power  system  operation  is  ensured  through  the  ability  to  independently  control  the  power  state 
of  individual  modules.  Additionally,  both  of  the  processors  used  in  the  system  support  dynamic  clock 
and  core  voltage  scaling  that  allows  processing  capabilities  to  be  matched  to  processing  needs, 
reducing  the  power  consumption  of  the  system  when  it  is  not  under  heavy  load. 
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Figure  55.  Sensoria  next-generation  WINS  3.0  embedded  system  modules. 

Within  the  WINS  3.0  system,  the  comprehensive,  open  software  framework  based  on  the  Linux  2.4 
kernel  developed  for  the  WINS  2.0  nodes  is  under  further  refinement  to  provide  a  robust  and 
powerful  operating  and  development  environment  for  custom  applications.  In  addition,  the  current 
WINS  3.0  design  represents  a  form  factor  reduction  over  both  the  1.0  and  2.0  systems. 

7  Concluding  Remarks  on  the  WINS  NG  Program 

7.1  SensIT  Program 

The  original  projected  goals  for  the  SensIT  program  were  to  provide  two  versions  of  the  WINS  NG 
development  system  to  the  SensIT  developers.  Initially,  these  were  planned  as  delivered  in  the  first 
and  third  year  of  the  program.  Within  the  course  of  this  effort,  there  was  significant  additional  effort 
not  originally  projected,  at  the  developers’  request  for  additional  capability  and  to  move  the  delivery 
of  the  2"d  generation  development  system  up  by  a  year.  In  addition  to  the  actual  platforms  supplied 
to  the  SensIT  community,  significant  development  work  was  performed  to  improve  those  systems 
and  to  support  and  enable  the  wider  development  community,  as  illustrated  with  the  examples 
presented  in  the  preceding  sections.  Overall,  the  support  of  the  SensIT  community  with  our  WINS 
NG  program  has  been  very  successful,  leading  to  significant  demand  for  the  delivered  WINS  NG  2.0 
nodes  at  the  program  completion. 

7.2  NRLSRSS 

The  support  of  the  Naval  Research  Laboratory  SRSS  program,  through  delivery  of  sensor  nodes, 
development  of  a  general  WINS  IP  radio  driver,  and  the  survey  of  alternative  Ultrawideband  radio 
options  for  WINS  systems,  has  also  been  very  successful.  Each  of  these  accomplishments  has  been 
met,  supporting  the  wider  networking  research  being  conducted  at  NRL. 

7.3  List  of  Publications  and  Inventions  Supported  by  the 
Contract 

To  date,  the  focus  of  the  SensIT  contract  on  providing  a  hardware  platform  to  the  community  has 
not  resulted  in  any  technical  journal  publications.  However,  that  development  work  has  been 
described  in  technical  conference  papers  partially  developed  within  the  SensIT  program  to  date, 
including: 

1)  W.  Merrill,  K.  Sohrabi,  L.  Girod,  J.  Elson,  F.  Newberg,  and  W.  Kaiser,  “Open  Standard 
Development  Platforms  for  Distributed  Sensor  Networks”,  AeroSense  Conference,  Orlando  FL, 
April  5,  2002. 
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2)  K.  Sohrabi,  W.  Merrill,}.  Elson,  L.  Girod,  F.  Newberg,  and  W.  Kaiser,  “Scaleable  Self-Assembly 
for  Ad  Hoc  Wireless  Sensor  Networks”,  Proceedings  of  tbe  IEEE  CAS  Workshop  on  Wireless 
Communications  and  Networking,  Pasadena,  CA,  Sept.  5,  2002. 

3)  William  M.  Merrill,  Fredric  Newberg,  Kathy  Sohrabi,  William  Kaiser,  and  Greg  Pottie, 
“Collaborative  Networking  Requirements  for  Unattended  Ground  Sensor  Systems”,  accepted  to  the 
2003  IEEE  Aerospace  Conference,  March  8-15,  2003,  Big  Sky,  MT. 

4)  F.  Newberg,  W.  M.  Merrill,  D.  Mclntire,  B.  Schiffer,  J.  Elson,  L.  Girod,  K.  Sohrabi,  and  W.  J. 
Kaiser,  “Networked,  Tactical  Embedded  Platforms  for  Unattended  Ground  Sensor  (UGS) 
Applications”,  the  28th  Annual  GOMAC  Tech  Conference,  March  31,  2003  to  April  3,  2003,  Tampa, 
Florida. 

5)  D.  Mclntire,  W.  M.  Merrill,  F.  Newberg,  K.  Sohrabi,  W.  J.  Kaiser,  “Energy  Aware  Networked 
Embedded  Systems  for  Tactical  Unattended  Ground  Sensors”,  the  Proceedings  of  SPIE,  Unattended 
Ground  Sensor  Technologies  and  Applications  V,  AeroSense  2003,  April  21-25,  2003,  Orlando,  FL. 
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